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 <charlie@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html