how to inspect changes from one repo, merge them into another?

sneakyimp

GIT has changed my life. It seems clear to me that I must better understand the full range of benefits it offers. I'm wondering if someone can help me understand how I might use it in the following context.

I have a git repo with many many files in it. This repo is very precious to me. I would like to collaborate with someone to work on the files in this repo without granting them access to the repo. I don't want to give them write access to the precious repo. We'll call that repo precious. In fact, I'd prefer they also didn't have direct read access or know where the repo actually lives.

So it seems to me that I must create another repo? Let's call this repo work_repo. This work_repo does not need the entire history of the precious repo. It just needs the latest files. There's no harm in this work_repo having the entire history of precious, though. I need to grant access to work_repo to my collaborator so that he can make changes. When these changes come back, I need to compare them to my working directory in precious to evaluate what changes have been made and whether or not to include them.

Can anyone suggest a good work process here? Can I get away with only one working directory on my workstation and switch it back and forth between precious and work_repo? Would that be accomplished by changing remotes? What happens when I stash changes?

laserlight

For precious, you would "prefer they also didn't have direct read access or know where the repo actually lives" because you do not want them to destroy what is in that repository, whether by accident or out of malice?

I ask this because you also wrote that "there's no harm in this work_repo having the entire history of precious". If so, it seems to me that you can afford to designate the main branch as precious, then require the other party to work in a feature branch. Even if the person tries to corrupt the main branch out of malice, you retain a local copy that is as authoritative as the remote one anyway.

This way, when ready, you can just pull the feature branch and use git diff/difftool.

sneakyimp

laserlight;11051777 wrote:
For precious, you would "prefer they also didn't have direct read access or know where the repo actually lives" because you do not want them to destroy what is in that repository, whether by accident or out of malice?

Say I want to commit all changes to the precious repo myself. Chalk it up to paranoia or selfishness or business reasons or espionage or racism or anything you like. I don't want to create a login for this person on the machine that hosts the precious repo. I want to inspect all changes made by this collaborator. I want to check them in myself.

laserlight;11051777 wrote:
I ask this because you also wrote that "there's no harm in this work_repo having the entire history of precious". If so, it seems to me that you can afford to designate the main branch as precious, then require the other party to work in a feature branch. Even if the person tries to corrupt the main branch out of malice, you retain a local copy that is as authoritative as the remote one anyway.

Let me emphasize that precious is precious. Under no circumstances is collaborator X to be connecting to the machine on which precious is hosted. Assume, if you like, that other devs with access to precious would be scandalized by the involvement of collaborator X. Or alternatively that our distributed organization would like to have all commits pushed to the repo from a single individual from a single IP address using only one username -- just for the sake of appearing monolithic to our client.

laserlight

sneakyimp wrote:
Let me emphasize that precious is precious. Under no circumstances is collaborator X to be connecting to the machine on which precious is hosted.

Those are two different issues: where repositories are concerned, yes, precious is precious, but since this is distributed version control, as long as you have one pristine copy of the repository, you can always designate that as precious.

sneakyimp wrote:
Assume, if you like, that other devs with access to precious would be scandalized by the involvement of collaborator X. Or alternatively that our distributed organization would like to have all commits pushed to the repo from a single individual from a single IP address using only one username -- just for the sake of appearing monolithic to our client.

You should provide collaborator X with the files and require him/her to send you patches that you then merge by yourself. Your usual diff tools will suffice.

sneakyimp

laserlight;11051787 wrote:
Those are two different issues: where repositories are concerned, yes, precious is precious, but since this is distributed version control, as long as you have one pristine copy of the repository, you can always designate that as precious.

The idea of shuffling complete copies of the (sizable) repo around just to make sure I have a pristine copy sounds a bit onerous. And restoring a much-used and oft-pulled, oft-committed repo due to the actions of one individual sounds to me like it might be a chore as well. It would simply not do to have any additional administrative burden and/or problems with the precious repo.

laserlight;11051787 wrote:
You should provide collaborator X with the files and require him/her to send you patches that you then merge by yourself. Your usual diff tools will suffice.

Sure, I could simply create a TAR archive of the files and send them to Collaborator X, but then the advantages of git to help keep my changes in sync with those of Collaborator X are completely lost, no? Or do you mean I should just send him a copy of my working directory (with .git folder and all)? I see that git allows one to create patches and apply them quite easily but I'm still having a little trouble understanding conceptually how my working directory can be kept in sync with that of Collaborator X and where I can also continue to commit changes to precious.

laserlight

sneakyimp wrote:
The idea of shuffling complete copies of the (sizable) repo around just to make sure I have a pristine copy sounds a bit onerous. And restoring a much-used and oft-pulled, oft-committed repo due to the actions of one individual sounds to me like it might be a chore as well. It would simply not do to have any additional administrative burden and/or problems with the precious repo.

Well, with something like gitolite you can make it such that that individual only can push to a particular branch. In such a case, his/her actions can only affect that branch, hence master remains pristine.

sneakyimp wrote:
Sure, I could simply create a TAR archive of the files and send them to Collaborator X, but then the advantages of git to help keep my changes in sync with those of Collaborator X are completely lost, no?

As in Collaborator X will continue to make changes, rather than do this as a one-off thing?

sneakyimp

laserlight;11051797 wrote:
Well, with something like gitolite you can make it such that that individual only can push to a particular branch. In such a case, his/her actions can only affect that branch, hence master remains pristine.

Good to know!

laserlight;11051797 wrote:
As in Collaborator X will continue to make changes, rather than do this as a one-off thing?

Yes, this is not a one-off thing. My changes must get to Collaborator X and his changes must get to me. I was sort of imagining I might create a bare repo, work_repo and grant Collaborator X access to this repo and then I might manage this by adding/switching remotes on my working directory, but I am unsure what it really means to switch/add a remote. I'm also concerned that Collaborator X's involvement becomes apparent in previous, which is not acceptable.

laserlight

Ah, I had a Eureka! moment in the shower, but no, I did not run out naked to post this 🙂

I propose that you have one server to host the precious repository and another server to host the x_files repository.

The precious repository will be directly accessed, both read and write, by you and your trusted collaborators. The x_files repository will be a clone of the precious repository, periodically pulling from the precious repository (e.g., a cron job to pull every 5 minutes or something).

You can setup gitolite on the server hosting the x_files repository. Collaborator X will have read only access to master and all branches except for feature branches with a prefix that will not conflict with any of the feature branches of your collaborators (just in case), or maybe use personal branches (I'm not sure).

Whenever Collaborator X wants to work on a feature, he/she will branch from master into a feature branch and work on it, pushing to the corresponding feature branch on the x_files repository. When you are notified that the feature has been baked to perfection (in the opinion of Collaborator X), you will change your remote to point to the x_files, then pull the feature branch. Upon doing this, you can use git diff/difftool as per normal. When you are ready to merge into master, you do a squashed merge. I believe that when you commit the squashed merge, it will automatically use your username/email, but if not you can override with --author. Then, you change your remote to point back to precious, then push.

This way, precious will only see the changes committed with your username/email. master on x_files will be updated with that commit. The feature branch on x_files can be discarded instead of having to deal with the divergence, with a new feature branch created for the next feature based on the updated master.

sneakyimp

Bless you for this. It's going to take some time for me to digest and comprehend it. I think I understand the basic idea, though.