Re: auto-merge after push?

"Michael S. Tsirkin" <mst@redhat.com> writes:

 - If you choose to detach-on-push, the user who _thought_ was advancing
   the history of a branch using the work tree will get very confusing
   results.  The branch will be advanced by the push, and the work tree
   user is required to notice the situation, later at some point merging
   the work done in the work tree that went to the detached HEAD state.

 - What happens if the automerge gets conflict?

Having said that, I think it is a _wrong_ approach to try summarizing the issues along these lines, without stating the most fundamental restriction.

If the push-from-sideways is done without any coordination between the person pushes and the person who uses the work tree, _any_ solution that modifies the work tree behind the back of that work-tree person will not work without surprising him, so listing the possible surprises is pointless.

On the other hand, all of the above "issues" (including yours) will become only implementation details of a workflow when there is a coordination between the pusher and the work-tree person. In the most trivial case, both are you, and the repository with the work tree is your private working area.

So I would suggest stressing the need for this coordination before starting to list the "issues".

Be it "detach" or "automerge", the workflow helped with the patch is merely a deviation of the mothership-satellite configuration (look for "satellite" in the FAQ) where you push from satellite to mothership (each has its own work tree) to achieve logically what you would want to perform with a pull in the other direction, that is:

 satellite$ git push mothership:project master:refs/remotes/satellite/master
 satellite$ ssh mothership 'cd project && git merge remotes/satellite/master'

The necessary "coordination" between the two repositories is that the last step, "merge what was pushed", must be done when the work tree checked out in the mothership repository is in a state that is suitable for performing the merge, e.g. no extra change to the index that is unrelated to the merge, no local change that interferes with the merge, etc.

The auto-merge-upon-push patch by Dscho, however, places a further restriction on top of the stock satellite-mothership configuration, exactly because it is automated. In an unautomated workflow, you can afford to choose _when_ to merge, independent from when to push:

 satellite$ git push mothership:project master:refs/remotes/satellite/master
 satellite$ ssh mothership
 mothership$ cd project
 ... work further to finish off what you did on the mothership ...
 mothership$ git commit
 mothership$ git merge remotes/satellite/master

Typically, when you are done (for the day, for example) on satellite, you push it out to the mothership, even though the mothership repository's work tree may have independent local changes (aka WIP) you have left when you last worked there. After switching to work in the mothership, you can continue working on the WIP to finish it before merging what you did on the satellite the previous day.

The automated way will trade this flexibility off with convenience (you do not have to have the interactive session on the mothership only to perform the merge), so you will be required to leave the mothership work tree and the index in a good shape any time you might want to push into it from the satellite. It is a small price to pay, and depending on the situation (the most obvious is when you do not even have an interactive shell access to the mothership) you may not even have that flexibility to begin with, in which case there is no downside.