Re: Segfault with merge-tree on multiple Git versions

Charlie Smurthwaite [off-list ref] writes:

I am experiencing a segmentation fault in various versions of Git using
different repositories.
...
Test Command
git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
8d6bdf012941d876b2279994e02f1bb0d5c26e7d
d5ef97ac407d945f231cd7c8fb1cfe48b3a12083

Thanks for a report (and thanks to John and Thomas for finding the
typo).

Nobody I know uses merge-tree; the last real change we did was back
from July 2010, and the only reason I was looking at it recently was
because I was planning to write a new merge strategy using it.

Mind if I ask what you are using it for?

On 27/03/13 17:06, Junio C Hamano wrote:

Charlie Smurthwaite [off-list ref] writes:

quoted

I am experiencing a segmentation fault in various versions of Git using
different repositories.
...
Test Command
git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
8d6bdf012941d876b2279994e02f1bb0d5c26e7d
d5ef97ac407d945f231cd7c8fb1cfe48b3a12083

Thanks for a report (and thanks to John and Thomas for finding the
typo).

Nobody I know uses merge-tree; the last real change we did was back
from July 2010, and the only reason I was looking at it recently was
because I was planning to write a new merge strategy using it.

Mind if I ask what you are using it for?

Thank you everybody for investigating this and creating a patch. Can I 
assume that this fix will reach somebody who can apply it to master?

With regard our use, we run an SCM hosting service http://codebasehq.com 
and are in the process of deploying a merge-request feature. We use 
git-merge-tree to determine whether a Git merge can be completed 
automatically (without manual conflict resolution), and if so offer the 
user a button to execute an actual merge. If there is a better way to do 
this, I'd be happy to consider it.

Charlie

On 27/03/13 17:06, Junio C Hamano wrote:

Charlie Smurthwaite [off-list ref] writes:

quoted

I am experiencing a segmentation fault in various versions of Git using
different repositories.
...
Test Command
git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
8d6bdf012941d876b2279994e02f1bb0d5c26e7d
d5ef97ac407d945f231cd7c8fb1cfe48b3a12083

Thanks for a report (and thanks to John and Thomas for finding the
typo).

Nobody I know uses merge-tree; the last real change we did was back
from July 2010, and the only reason I was looking at it recently was
because I was planning to write a new merge strategy using it.

Mind if I ask what you are using it for?

I am also using this to obtain a diff that would be applied if a merge 
were to be run. Is there a better way to obtain this information that is 
more commonly used?

Charlie Smurthwaite [off-list ref] writes:

I am also using this to obtain a diff that would be applied if a merge 
were to be run. Is there a better way to obtain this information that is 
more commonly used?

You can do an actual merge using detached HEAD:

  $ git checkout --detach upstream-branch
  $ git merge topic-branch

This has the benefit that if there are conflicts, you can resolve them
here and commit the result so that rerere can auto-resolve them later.

Are you looking for something that can be run in a bare repo?

On 27/03/13 18:06, Jed Brown wrote:

Charlie Smurthwaite [off-list ref] writes:

quoted

I am also using this to obtain a diff that would be applied if a merge
were to be run. Is there a better way to obtain this information that is
more commonly used?

You can do an actual merge using detached HEAD:

   $ git checkout --detach upstream-branch
   $ git merge topic-branch

This has the benefit that if there are conflicts, you can resolve them
here and commit the result so that rerere can auto-resolve them later.

Are you looking for something that can be run in a bare repo?

Yes, I would need to be able to do this on a bare repo for my use case. 
Thanks!

Charlie Smurthwaite [off-list ref] writes:

Yes, I would need to be able to do this on a bare repo for my use case. 

And if it's on the server, you don't want this to be observable, so
you don't want HEAD to move around. I don't know a better way than:

  $ git clone --shared -b upstream-branch bare-repo.git /tmp/merge-repo
  $ cd /tmp/merge-repo
  $ git pull URL incoming-branch

Cloning with --shared just writes a path into .git/objects/info/alternatives
and it doesn't need to be on the same file system (unlike --local).

Since 'git merge-tree' just works with trees, it has less information
than 'git merge'.

On Wed, Mar 27, 2013 at 02:16:24PM -0500, Jed Brown wrote:

Charlie Smurthwaite [off-list ref] writes:

quoted

Yes, I would need to be able to do this on a bare repo for my use case. 

And if it's on the server, you don't want this to be observable, so
you don't want HEAD to move around. I don't know a better way than:

  $ git clone --shared -b upstream-branch bare-repo.git /tmp/merge-repo
  $ cd /tmp/merge-repo
  $ git pull URL incoming-branch

Cloning with --shared just writes a path into .git/objects/info/alternatives
and it doesn't need to be on the same file system (unlike --local).

Since 'git merge-tree' just works with trees, it has less information
than 'git merge'.

You could use a temporary index and do something like:

	rm -f TMP_INDEX
	GIT_INDEX_FILE=TMP_INDEX
	export GIT_INDEX_FILE
	git read-tree -m $base $ours $theirs &&
	git merge-index git-merge-one-file -a

then inspect that with "git diff-index --cached $ours".

Note that this will fail if there are conflicts and I don't know what
git-merge-tree will do in that case.

On Wed, Mar 27, 2013 at 07:45:21PM +0000, John Keeping wrote:

On Wed, Mar 27, 2013 at 02:16:24PM -0500, Jed Brown wrote:

quoted

Charlie Smurthwaite [off-list ref] writes:

quoted

Yes, I would need to be able to do this on a bare repo for my use case. 

And if it's on the server, you don't want this to be observable, so
you don't want HEAD to move around. I don't know a better way than:

  $ git clone --shared -b upstream-branch bare-repo.git /tmp/merge-repo
  $ cd /tmp/merge-repo
  $ git pull URL incoming-branch

Cloning with --shared just writes a path into .git/objects/info/alternatives
and it doesn't need to be on the same file system (unlike --local).

Since 'git merge-tree' just works with trees, it has less information
than 'git merge'.

You could use a temporary index and do something like:

	rm -f TMP_INDEX
	GIT_INDEX_FILE=TMP_INDEX
	export GIT_INDEX_FILE
	git read-tree -m $base $ours $theirs &&
	git merge-index git-merge-one-file -a

then inspect that with "git diff-index --cached $ours".

That is precisely how we do it at GitHub. You probably want to add in
"--aggressive" to your read-tree to cover a few more simple cases. If
there are conflicts, we just bail and say "this can't be merged", and
expect the user to do it themselves using git.

-Peff

On 27/03/13 20:01, Jeff King wrote:

On Wed, Mar 27, 2013 at 07:45:21PM +0000, John Keeping wrote:

quoted

On Wed, Mar 27, 2013 at 02:16:24PM -0500, Jed Brown wrote:

quoted

Charlie Smurthwaite [off-list ref] writes:

quoted

Yes, I would need to be able to do this on a bare repo for my use case.

And if it's on the server, you don't want this to be observable, so
you don't want HEAD to move around. I don't know a better way than:

   $ git clone --shared -b upstream-branch bare-repo.git /tmp/merge-repo
   $ cd /tmp/merge-repo
   $ git pull URL incoming-branch

Cloning with --shared just writes a path into .git/objects/info/alternatives
and it doesn't need to be on the same file system (unlike --local).

Since 'git merge-tree' just works with trees, it has less information
than 'git merge'.

You could use a temporary index and do something like:

	rm -f TMP_INDEX
	GIT_INDEX_FILE=TMP_INDEX
	export GIT_INDEX_FILE
	git read-tree -m $base $ours $theirs &&
	git merge-index git-merge-one-file -a

then inspect that with "git diff-index --cached $ours".

That is precisely how we do it at GitHub. You probably want to add in
"--aggressive" to your read-tree to cover a few more simple cases. If
there are conflicts, we just bail and say "this can't be merged", and
expect the user to do it themselves using git.

-Peff

This may be ideal. I will compare it with merge-tree to see which will 
suit best. Thank you everyone for your help here.

Charlie