Re: [ANNOUNCE] Git wiki

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 6, 2006, 06:53 UTC
Message-ID: <46a038f90605052353m2d2aca11weac7efee80c6fb35@mail.gmail.com>
In-Reply-To: <7vr738w8t4.fsf@assigned-by-dhcp.cox.net>

On 5/6/06, Junio C Hamano <junkio@cox.net> wrote:

> > If you use persistent file ids, you never miss it _AND_ you DO NOT WALK
> > THE COMMIT CHAIN! You still just match file ids in the two trees.
>
> It is unworkable.

+1 -- explicit file ids are evil. Arch/TLA demonstrated that amply... they are a serious annoyance to the end user, they have a lot of not-elegantly solvable cases (same file created with the same contents in several repos -- say via an emailed patch) that git gets right _today_.

They _are_ useful in a very small set of cases -- namely in the case of a naive mv, which git handles correctly today. Subtler things git sometimes does right, sometimes fails, but it can be made to be much smarter by interpreting content changes better, for instance all this talk about getting pickaxe to guess where the patch should be applied for a file that got split into 3.

But those subtler cases are totally impossible with explicit id tracking. I used Arch for a long time with very large trees, and renames coming left, right and centre. Explicit ids didn't help much, and the number of manual fixups we had to do was awful.

I am using GIT with the very same project, and just now, typing this, I realised that there are still many renames happening in the project. I had forgotten about it -- well, not really: I do use git-merge instead of cg-merge when I suspect there may be interesting cases ;-)

Of course, YMMV, and I have to confess I was a sceptic for a while... but now as an end-user dealing with messy projects, I say LIRAR: Linus Is Right About Renames.

OTOH,

Show 12 quoted lines

>> Try doing
>>
>> git diff v1.3.0..
>>
>> and think about what that actually _means_. Think about the fact that it
>> doesn't actually walk the commit chain at all: it diffs the trees between
>> v1.3.0 and the current one. What if the rename happened in a commit in
>> the middle?
>
> Then the automated renames detection will miss it given that the other
> accumulated differences are large enough, and the suggested workarounds
> _are_ precisely walking the commit chain.

I agree here with Pasky that after a while the automated renames/copy/splitup detection will miss the operation in cases where it would be interesting to note it to the user. IIRC git-rerere is the tool that knows about this (still voodoo to me how) and could be used to help here. At what (runtime) cost, I don't know, but that kind of walking history to tell me more interesting things about the diff is something that is usually worthwhile.

Usual disclaimers apply.

martin