Separate out the merge resolve from the actual getting of the
data. Also, update the resolve phase to take advantage of the
fact that we don't need to do the commit->tree object lookup
by hand, since all the actors involved happily just act on a
commit object these days.
If you set SHA1_FILE_DIRECTORY to something else than .git/objects
git-pull-script will store the fetched files in a location the rest of
the tools does not expect.
git-prune-script also ignores this setting, but I think this is good,
because pruning a shared tree to fit a single project means throwing
away a lot of useful data. :-)
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When the trivial "read-tree" merge fails, fall back on the (equally
trivial) automatic merge script instead of forcing the user to do
it by hand.
When _that_ fails, you get to do a manual merge.
reading a single tree too. That should speed up a
trivial merge noticeably.
Also, don't bother reading back the tree we just wrote
when we committed a real merge. It had better be the
same one we still have..
They sure as hell aren't perfect, but they allow you to do:
./git-pull-script {other-git-directory}
to do the initial merge, and if that had content clashes, you do
merge-cache ./git-merge-one-file-script -a
which tries to auto-merge. When/if the auto-merge fails, it will
leave the last file in your working directory, and you can edit
it and then when you're happy you can do "update-cache filename"
on it. Re-do the merge-cache thing until there are no files left
to be merged, and now you can write the tree and commit:
write-tree
commit-tree .... -p $(cat .git/HEAD) -p $(cat .git/MERGE_HEAD)
and you're done.
