Re: RFH: refactor read-tree

Hi,

On Sat, 8 Jul 2006, Linus Torvalds wrote:

On Sun, 9 Jul 2006, Johannes Schindelin wrote:

quoted

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