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 - : 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