Re: RFH: refactor read-tree

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 9, 2006, 14:55 UTC
Message-ID: <Pine.LNX.4.63.0607091650030.29667@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <Pine.LNX.4.64.0607082011060.5623@g5.osdl.org>

Hi,

On Sat, 8 Jul 2006, Linus Torvalds wrote:

Show 12 quoted lines

> 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