auto-merge after push?

auto-merge after push?

[Michael S. Tsirkin]

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

Thanks,
-- 
MST

Re: auto-merge after push?

[Jakub Narebski]

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

> 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

In general this is not possible, because pull can result in merge
conflicts, which you cannot resolve without access.  Why not push into
remotes, and when you are on second machine, complete pull by merging
changes?  See GitFaq (or GitTips, I don't remember which) where such
approach is described in more detail.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: auto-merge after push?

[Johannes Schindelin]

Hi,

On Mon, 11 May 2009, Michael S. Tsirkin wrote:

> 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

How about something like

$ git config alias.reverse-pull '!sh -c "git push remote HEAD:TO_MERGE && \
	ssh remote \"cd directory && \
		git merge TO_MERGE && git branch -d TO_MERGE\""'

?

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

Re: auto-merge after push?

[Michael S. Tsirkin]

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
> 
> Ciao,
> Dscho

Sounds good. But it looks like this patch is unlikely to be merged,
does it not?

-- 
MST

Re: auto-merge after push?

[Johannes Schindelin]

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

Re: auto-merge after push?

[Michael S. Tsirkin]

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

BTW, what exactly happens on conflict?

-- 
MST

Re: auto-merge after push?

[Johannes Schindelin]

Hi,

On Tue, 12 May 2009, Michael S. Tsirkin wrote:

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

With this patch?  The push is refused.

Ciao,
Dscho

Re: auto-merge after push?

[Johannes Schindelin]

Hi,

[assuming that you did not mean this mail to be private, I send the answer 
to the Git list...]

On Tue, 12 May 2009, 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.: :-)
> 
> OK. Could you send me the patch pls? gmane doesn't seem to have a "send
> to mail" coption.

It has.  It is a hidden function by the bot known as "Johannes 
Schindelin", listening on git@vger.kernel.org for requests:

http://article.gmane.org/gmane.comp.version-control.git/110251/raw

Ciao,
Dscho

Re: auto-merge after push?

[Michael S. Tsirkin]

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.

Same here. I've been using denyCurrentBranch=updateInstead for about a
week now. I find very useful.

> Of course, I always know what I am doing.

Haven't seen any issues so far.


> Ciao,
> Dscho
> 
> P.S.: :-)

-- 
MST

Re: auto-merge after push?

[Michael S. Tsirkin]

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.

-- 
MST

Re: auto-merge after push?

[Michael S. Tsirkin]

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?

-- 
MST

Re: auto-merge after push?

[Johannes Schindelin]

Hi,

On Sat, 11 Jul 2009, Michael S. Tsirkin wrote:

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

Well, I use it myself, what more can I say?

Ciao,
Dscho

Re: auto-merge after push?

[Junio C Hamano]

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

Re: auto-merge after push?

[Johannes Schindelin]

Hi,

On Sun, 12 Jul 2009, Junio C Hamano wrote:

> If Dscho is short on time, perhaps somebody else can improve upon the
> documentation part of the patch?

That would be fabulous.  It is not looking as if my Git time balance is 
going to improve (as far as Git is concerned) now that I accepted to take 
on more responsibilities in my day job.

It does not help, of course, that I wanted this jgit gui toy out to the 
public, either.

Ciao,
Dscho

Re: auto-merge after push?

[Michael S. Tsirkin]

On Sun, Jul 12, 2009 at 02:30:44PM -0700, Junio C Hamano wrote:
> 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?

-- 
MST

Re: auto-merge after push?

[Junio C Hamano]

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

Re: auto-merge after push?

[Michael S. Tsirkin]

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.

Re: auto-merge after push?

[Johannes Schindelin]

Hi,

On Wed, 15 Jul 2009, Michael S. Tsirkin wrote:

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

I do not use it.  But I added it upon explicit request.

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

Lemme look at that patch (it is pretty old by now...).

Actually, my patch has nothing to do with allowing only fast-forwards 
unless the push is forced.

The documentation states that a read-tree -u -m HEAD is performed.  This 
can fail when a file is not up-to-date.  As far as I can tell, read-tree 
-u -m HEAD refuses to update the index in such a situation.

So if there are files to be updated by the push which are dirty, the push 
will update the ref as requested, nevertheless error out, the index will 
be untouched, and so will be the working directory (unless I fscked up the 
patch, which is quite possible, as I was writing this just to get a 
quieter mailing list again).

One thing I got right, though, was the commit message.

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

Happily enough, it is the duty of the local guy to actually set the config 
variable.  And to allow the other guy (who might be one and the same guy a 
la "I am schizophrenic and me too") is also the privilege of the local 
guy.

Ciao,
Dscho