* 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
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.
rename 39021759c903a943a33a28cfbd5070d36d851581 15234
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