Subject: Re: Segfault with merge-tree on multiple Git versions

From: Charlie Smurthwaite <[email-masked]>
Date: Wed, 27 Mar 2013 21:10:59 +0000

On 27/03/13 20:01, Jeff King wrote:
> 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:
>>> Charlie Smurthwaite <[email-masked]> 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'.
>> 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