Re: auto-merge after push?

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jul 15, 2009 at 12:31:00PM -0700, Junio C Hamano wrote:
> "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.

I never use detach on push. Let's remove that option for now?

>  - What happens if the automerge gets conflict?

push is denied, unless you push with -f, then I think you get the new
head.  Note that merge is not the right word here: only fast forward is
done I think.  Right, Dscho?

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

Sure. I am just trying to figure out all the details before I try to
write this up. The coordination issue is obviously the main thing, I was
trying to enumerate the less obvious ones.

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

Thanks for the explanation.