Hi, On Sat, 8 Jul 2006, Linus Torvalds wrote: > 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". I see my problem: branch1 is not the "upstream" branch, but my own. Tsk. Too easy. Now, if only merge-tree knew about renames. *sigh*. > 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. Well, I think that at least the unpack_tree() thing should be relatively easy to extract. And the rest _should_ be relatively easy to clean up, provided we introduce a read_tree_options struct, which gets passed around a la "this" in Java/C++. Ciao, Dscho - : 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