auto-merge after push?

> Hi!
> I'm working on two machines, and git allows me to switch between them
> and sync by means of git pull. When one machine is behind a firewall, I
> can sometimes only do pushes, but then I have to rememeber to merge when
> I log into remote machine.
> 
> Is there a way to trigger merge on remote after push somehow,
> so that running on local machine:
> $ git push remote
> would be equivalent to
> $ ssh remote git pull local

> I'm working on two machines, and git allows me to switch between them 
> and sync by means of git pull. When one machine is behind a firewall, I 
> can sometimes only do pushes, but then I have to rememeber to merge when 
> I log into remote machine.
> 
> Is there a way to trigger merge on remote after push somehow,
> so that running on local machine:
> >git push remote
> would be equivalent to
> >ssh remote git pull local

> The thing is, a merge can fail.  And then you already need direct access 
> to the working directory in question.
> 
> If you were actually talking about fast-forward pushes (because you did 
> the merge locally already), this might help you:
> 
> 	http://thread.gmane.org/gmane.comp.version-control.git/110251
> 
> Ciao,
> Dscho

> On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:
> > The thing is, a merge can fail.  And then you already need direct access 
> > to the working directory in question.
> > 
> > If you were actually talking about fast-forward pushes (because you did 
> > the merge locally already), this might help you:
> > 
> > 	http://thread.gmane.org/gmane.comp.version-control.git/110251
> 
> Sounds good. But it looks like this patch is unlikely to be merged, does 
> it not?

> Hi,
> 
> On Mon, 11 May 2009, Michael S. Tsirkin wrote:
> 
> > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:
> > > The thing is, a merge can fail.  And then you already need direct access 
> > > to the working directory in question.
> > > 
> > > If you were actually talking about fast-forward pushes (because you did 
> > > the merge locally already), this might help you:
> > > 
> > > 	http://thread.gmane.org/gmane.comp.version-control.git/110251
> > 
> > Sounds good. But it looks like this patch is unlikely to be merged, does 
> > it not?
> 
> Unlikely to be merged by Junio?  Without success stories, certainly.
> 
> But you can do the same as I did: run your local Git with that patch.  I 
> am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  
> It works beautifully here.
> 
> Of course, I always know what I am doing.
> 
> Ciao,
> Dscho
> 
> P.S.: :-)

> On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:
> 
> > On Mon, 11 May 2009, Michael S. Tsirkin wrote:
> > 
> > > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:
> > > > The thing is, a merge can fail.  And then you already need direct access 
> > > > to the working directory in question.
> > > > 
> > > > If you were actually talking about fast-forward pushes (because you did 
> > > > the merge locally already), this might help you:
> > > > 
> > > > 	http://thread.gmane.org/gmane.comp.version-control.git/110251
> > > 
> > > Sounds good. But it looks like this patch is unlikely to be merged, does 
> > > it not?
> > 
> > Unlikely to be merged by Junio?  Without success stories, certainly.
> > 
> > But you can do the same as I did: run your local Git with that patch.  I 
> > am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  
> > It works beautifully here.
> > 
> > Of course, I always know what I am doing.
> 
> BTW, what exactly happens on conflict?

> Hi,
> 
> On Mon, 11 May 2009, Michael S. Tsirkin wrote:
> 
> > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:
> > > The thing is, a merge can fail.  And then you already need direct access 
> > > to the working directory in question.
> > > 
> > > If you were actually talking about fast-forward pushes (because you did 
> > > the merge locally already), this might help you:
> > > 
> > > 	http://thread.gmane.org/gmane.comp.version-control.git/110251
> > 
> > Sounds good. But it looks like this patch is unlikely to be merged, does 
> > it not?
> 
> Unlikely to be merged by Junio?  Without success stories, certainly.
> 
> But you can do the same as I did: run your local Git with that patch.  I 
> am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  
> It works beautifully here.

> Hi,
> 
> On Mon, 11 May 2009, Michael S. Tsirkin wrote:
> 
> > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:
> > > The thing is, a merge can fail.  And then you already need direct access 
> > > to the working directory in question.
> > > 
> > > If you were actually talking about fast-forward pushes (because you did 
> > > the merge locally already), this might help you:
> > > 
> > > 	http://thread.gmane.org/gmane.comp.version-control.git/110251
> > 
> > Sounds good. But it looks like this patch is unlikely to be merged, does 
> > it not?
> 
> Unlikely to be merged by Junio?  Without success stories, certainly.
> 
> But you can do the same as I did: run your local Git with that patch.  I 
> am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  
> It works beautifully here.
> 
> Of course, I always know what I am doing.
> 
> Ciao,
> Dscho
> 
> P.S.: :-)

> On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:
> > Hi,
> > 
> > On Mon, 11 May 2009, Michael S. Tsirkin wrote:
> > 
> > > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:
> > > > The thing is, a merge can fail.  And then you already need direct access 
> > > > to the working directory in question.
> > > > 
> > > > If you were actually talking about fast-forward pushes (because you did 
> > > > the merge locally already), this might help you:
> > > > 
> > > > 	http://thread.gmane.org/gmane.comp.version-control.git/110251
> > > 
> > > Sounds good. But it looks like this patch is unlikely to be merged, does 
> > > it not?
> > 
> > Unlikely to be merged by Junio?  Without success stories, certainly.
> > 
> > But you can do the same as I did: run your local Git with that patch.  I 
> > am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  
> > It works beautifully here.
> > 
> > Of course, I always know what I am doing.
> > 
> > Ciao,
> > Dscho
> > 
> > P.S.: :-)
> 
> So here's a success story:
> 
> I have been using this patch for 1 month now, on all my trees, with
> denyCurrentBranch=updateInstead
> I find it very useful for several reasons:
> - I commit on my development machine, then push to test machine
> - I debug and fix an issue on test machine, push change back to devel machine
> - If I'm going from home to the office, I just push into the machine at the office, and when
>   I get there the tree is set up and ready for me to hack on, same on my way back
> 
> Of course all the same things can be accomplished with a set of scripts,
> but frankly I never got them to be as flexible and easy to use as this
> patch. This patch simply works for me. Thanks for it Johannes, and I
> hope it makes it into upstream at some point, so that more people can
> benefit from it.

> On Thu, Jun 11, 2009 at 01:40:20PM +0300, Michael S. Tsirkin wrote:
> > On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:
> > > Hi,
> > > 
> > > On Mon, 11 May 2009, Michael S. Tsirkin wrote:
> > > 
> > > > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:
> > > > > The thing is, a merge can fail.  And then you already need direct access 
> > > > > to the working directory in question.
> > > > > 
> > > > > If you were actually talking about fast-forward pushes (because you did 
> > > > > the merge locally already), this might help you:
> > > > > 
> > > > > 	http://thread.gmane.org/gmane.comp.version-control.git/110251
> > > > 
> > > > Sounds good. But it looks like this patch is unlikely to be merged, does 
> > > > it not?
> > > 
> > > Unlikely to be merged by Junio?  Without success stories, certainly.
> > > 
> > > But you can do the same as I did: run your local Git with that patch.  I 
> > > am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  
> > > It works beautifully here.
> > > 
> > > Of course, I always know what I am doing.
> > > 
> > > Ciao,
> > > Dscho
> > > 
> > > P.S.: :-)
> > 
> > So here's a success story:
> > 
> > I have been using this patch for 1 month now, on all my trees, with
> > denyCurrentBranch=updateInstead
> > I find it very useful for several reasons:
> > - I commit on my development machine, then push to test machine
> > - I debug and fix an issue on test machine, push change back to devel machine
> > - If I'm going from home to the office, I just push into the machine at the office, and when
> >   I get there the tree is set up and ready for me to hack on, same on my way back
> > 
> > Of course all the same things can be accomplished with a set of scripts,
> > but frankly I never got them to be as flexible and easy to use as this
> > patch. This patch simply works for me. Thanks for it Johannes, and I
> > hope it makes it into upstream at some point, so that more people can
> > benefit from it.
> 
> Hey, Johannes, so .. how about trying to push it out to Junio?
> Maybe if this lands in pu more people will try it and there
> will be more success stories?

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Well, I use it myself, what more can I say?
> 
> It's rather hard to justify a feature that is available to the general
> public with documentation that only says "we tell you what happens in
> terms of low-level commands when you use this feature, we warn you that
> this has its own set of possible complications, but we do not specify what
> they are, nor how to recover from them. You should know what you are doing
> if you choose to use it".
> 
> That is not very helpful.
> 
> If this _were_ implemented as a sample hook on the receiving end, with
> ample comments that the users can read to undersand the issues before
> deciding to install it on their repositories, it might have been an easier
> sell.
> 
> If Dscho is short on time, perhaps somebody else can improve upon the
> documentation part of the patch?  It's a long time ago that I took a look
> at the patch text itself but I had a recorrection that the code itself was
> reasonable (and it is a well known fact that I tend not to notice bugs in
> Dscho's code so it is not a very useful thing for me to go back to look at
> the code again now when I am short on brain cycles).
> 

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

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

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

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

> On Mon, May 11, 2009 at 11:03:27PM +0200, Johannes Schindelin wrote:
> > Hi,
> > 
> > On Mon, 11 May 2009, Michael S. Tsirkin wrote:
> > 
> > > On Mon, May 11, 2009 at 05:18:06PM +0200, Johannes Schindelin wrote:
> > > > The thing is, a merge can fail.  And then you already need direct access 
> > > > to the working directory in question.
> > > > 
> > > > If you were actually talking about fast-forward pushes (because you did 
> > > > the merge locally already), this might help you:
> > > > 
> > > > 	http://thread.gmane.org/gmane.comp.version-control.git/110251
> > > 
> > > Sounds good. But it looks like this patch is unlikely to be merged, does 
> > > it not?
> > 
> > Unlikely to be merged by Junio?  Without success stories, certainly.
> > 
> > But you can do the same as I did: run your local Git with that patch.  I 
> > am actually growing fonder and fonder of denyCurrentBranch=updateInstead.  
> > It works beautifully here.
> > 
> > Of course, I always know what I am doing.
> > 
> > Ciao,
> > Dscho
> > 
> > P.S.: :-)
> 
> OK. Could you send me the patch pls? gmane doesn't seem to have a "send
> to mail" coption.