Re: Handling renames.

From: Junio C Hamano <junkio@cox.net>
Date: Oct 22, 2005, 02:10 UTC
Message-ID: <7vbr1is3m4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051022015109.GO30889@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 8 quoted lines

>> I'm convinced that git handles renames better than any other SCM ever. 
>> Exactly because we figure it out when it matters.
>
> It matters at least every time you show per-file history and every time
> you merge cross the rename. I think that can be both pretty common if
> you ever do the rename. That means you can do an expensive guess
> every time you hit that, and the guess can get it wrong, in which case
> there is no way around that and you lose.

I think it is OK for the higher level layer (like your single-file-history follower) to use what you outlined with "edges", as either a hint/request from the user and/or a cache of what the expensive and unreliable thing figured out.

I however do not necessarily think adding the "edges" information as an optional second item on "parent " line in a commit is a good idea. Rather, treating the set of "edges" just like we treat the grafts feel more appropriate to me. IOW, create .git/info/edges and keep your edge information there.