Re: auto-merge after push?

[Junio C Hamano <gitster@pobox.com>]

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

> So, let me summarize the issues:
> - if the tree is pushed into while files are being actively read
>   (e.g. built from), the build will get an inconsistent state
> - even worse if one of the files is open for editing or is being written
>   into: the file will get corrupted
> - if there are uncommitted changes in the tree, the push is denied
>
> Are there others?

 - 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.