* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> [...] Ie if you notice a rename, you first commit the rename (and you
> can _see_ it's a rename, since the object didn't change, and the sha1
> stayed the same, which in git-speak means that it is the same object,
> ie that _is_ a rename as far as git is concerned), and then you create
> the "this is the data that changed" as a _second_ commit.
ok, i accept your point of not putting this into such a low level as the
object abstraction. Was a bad idea.
but i dont think the above would be enough: there can be renames of
objects that have the same sha1 hash as other objects in the same tree,
and developers want to track individual objects, regardless of whether
other files share the same content. So some formal operation would be
needed to signal renames - e.g. to embedd it in the commit object, per
David's suggestion.
The thing i tried to avoid was to list long filenames in the commit
(because of the tree hierarchy we'd need to do tree-absolute pathnames
or something like that, and escape things, and do lookups - duplicating
a VFS which is quite bad) - it would be better to identify the rename
source and target via its tree object hash and its offset within that
tree. Such information could be embedded in the commit object just fine.
Something like:
me bb95843a5a0f397270819462812735ee29796fb4
tree 1756b578489f93999ded68ae347bef7d6063101c
parent 9f02d4d233223462d3f6217b5837b786e6286ba4
author
committer
rename 39021759c903a943a33a28cfbd5070d36d851581 15234
9f02d4d233223462d3f6217b5837b786e6286ba4 16163
?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
