Re: RFH: refactor read-tree

On Sun, 9 Jul 2006, Johannes Schindelin wrote:

I also played a little with git-merge-tree, because it seems so much 
simpler and easier to refactor. But there is a problem: Either I call it 
the wrong way, or it does not yet work correctly: I tried

	git-merge-tree $(git-merge-base branch1 branch2) branch1 branch2

with what is in 'next'. But it only showed the _new_ files, not the 
modified ones.

What git-merge-tree does is to show the _difference_ to "branch1".

So if the result of the merge would be totally identical to "branch1", 
then git-merge-tree should be totally silent.

The basic idea is that "branch1" should be your current branch, and it 
obviously is also expected to match (more or less) the current index. So 
you can do a merge by

 - reading in "branch1" into the index:

	GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1

 - doing a "git-merge-tree $base $branch1 $branch2"

 - using the _result_ of "git-merge-tree" to modify the index you just 
   read in.

 - write out the end result as the result of the merge.

And yes, I agree 100% that "git-read-tree" has become an unholy mess. I 
looked at it, and I think it's unfixable. I considered re-writing it from 
scratch, at least for some specific cases, but I couldn't bring myself to 
do it.

			Linus