Stefan Beller <sbeller@xxxxxxxxxx> writes:
> I have rethought about the idea of GUIDs as proposed by Jeff and wanted
> to give a reply. After rereading this message, I think my thoughts are
> already included via:
>
> - you're doing the work at the wrong point for _another_ reason. You're
> freezing your (crappy) algorithm at tree creation time, and basically
> making it pointless to ever create something better later, because even
> if hardware and software improves, you've codified that "we have to
> have crappy information".
>
> --
> My design proposal for these "rename hints" would be a special trailer,
> roughly:
>
> Rename: LICENSE -> legal.txt
> Rename: t/* -> tests/*
>
> or more generally:
>
> Rename: <pathspec> <delim> <pathspec>
Yes, it is a non starter to have that baked in the log message of a
commit object. The principle Linus lays out in the message does not
reject such hints stored outside baked-in data structure, which
allows mistakes to be corrected without affecting the real history,
though.
Another thing that makes what you wrote above of dubious value is
that it attaches such hints to "a commit" (whether baked inside the
log message, or as some form of "notes" that can be associated with
a specific commit); it adds hints at a wrong place.
Given identical pair of trees <X,Y> that are wrapped in two pairs of
commits <A> and <B> where A^{tree}=B^{tree} and A^^{tree}=B^^{tree},
we do not want to have to give duplicated hints for A and B, to help
"git show A" and "git show B" to behave the same.
Rather, if we said "these two blobs A and B are similar and we want
diffcore-rename to pair them, no matter where they appear in any two
trees", then "git diff -M X Y", where X and Y may not have any
ancestry relationship (they may not even be commits) can be told
that the blob A that is in tree X and the blob B that is in tree Y
are renames or copies, no matter where in these trees the pair of
blobs appear, and no matter how X and Y are related (or unrelated)
in the history.
That is a bigger reason why annotating a commit may be a bad way to
go.
