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 <char...@atechmedia.com> 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
        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.


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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to