Re: more git updates..

[Junio C Hamano <junkio@cox.net>]

>>>>> "CL" == Christopher Li <lkml@chrisli.org> writes:

CL> On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
>> 
>> But I am wondering what your plans are to handle renames---or
>> does git already represent them?
>> 

CL> Rename should just work.  It will create a new tree object and you
CL> will notice that in the entry that changed, the hash for the blob
CL> object is the same.

Sorry, I was unclear.  But doesn't that imply that a SCM built
on top of git storage needs to read all the commit and tree
records up to the common ancestor to show tree diffs between two
forked tree?

I suspect that another problem is that noticing the move of the
same SHA1 hash from one pathname to another and recognizing that
as a rename would not always work in the real world, because
sometimes people move files *and* make small changes at the same
time.  If git is meant to be an intermediate format to suck
existing kernel history out of BK so that the history can be
converted for the next SCM chosen for the kernel work, I would
imagine that there needs to be a way to represent such a case.
Maybe convert a file rename as two git trees (one tree for pure
move which immediately followed by another tree for edit) if it
is not a pure move?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/