Re: [idea] File history tracking hints

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 3, 2017, 00:45 UTC
Message-ID: <xmqq3771m54g.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbghnWmvQweup=Z79HnVQQCMM65CKgEO3oqDoRp-Bj=2Q@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 20 quoted lines

> 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.