quoted
Aye, that will require some metadata on the git side (the hack,
suggested by Linus, of using git hashes to notice moves won't work).
So, why won't it work?
Because two files can legitimately have identical contents without
being ``the same'' file from the VC system's point of view.
In other words, two files may happen to have the same contents but
have distinct histories.
Juliusz
On Tue, 2005-04-19 at 10:22 +0200, Juliusz Chroboczek wrote:
quoted
quoted
Aye, that will require some metadata on the git side (the hack,
suggested by Linus, of using git hashes to notice moves won't work).
quoted
So, why won't it work?
Because two files can legitimately have identical contents without
being ``the same'' file from the VC system's point of view.
In other words, two files may happen to have the same contents but
have distinct histories.
Eh, let's not talk using integral/summation view across all the patches
that ever could have come in against the file. We're hamstringing
ourselves if we do that, and it's not what darcs does. darcs looks at a
differential view of the changes, and for a mv, it looks at it when it
happens.
darcs does a "darcs mv" to commit a "file move patch" to whatever
logging or patch repository it keeps below the surface.
The equivalent in git would be to have a given tree, move a file via
bash's mv, and then checkpoint a new tree. (I'm sure there's details in
there, but that's plumbing, and what we have Petr for.)
A differential comparison of the two trees shows no content changed, but
a file label was modified. Ergo, a rename occurred.
QED.
~r.