Re: Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer)

[Junio C Hamano <gitster@pobox.com>]

Nico Williams <nico@cryptonector.com> writes:

> I don't find file rename heuristics to be "simple", and they're often

I think you need to re-read what Tytso wrote before reacting.  He
never said rename and copy heuristics is simple.  His statement was
that choosing *NOT* to record the "file A was renamed to B and C was
copied to D in this commit" in commit objects can be thought as a
choice to keep the system simple.

But the decision not to record renames and copies in commits is not
about simplicity but it is more about correctness.  People record
wrong renames and not all renaming changes are made with "git mv".

Through your GUI IDE, you may choose "Copy file" menu and make a
copy of an existing file F to file G, and edit file G extensively
and record the result in a commit.  No matter how heavy the edit
after copying is, your IDE would remember that G came originally by
copying from F so it should be able to record the fact that G was
copied from F in the resulting commit.

But recording that as a copy may be a *wrong* thing to do in the
first place.  The IDE cannot guess *why* you copied F to G in the
first place.  Perhaps it was because your project requires you to
reproduce boilerplate license notice in the comment at the beginning
of each and every file, and copying an existing file as a whole,
removing everything after that initial boilderplate comment, and
write everything else afresh was the easiest way for you to work.
If you inspect the resulting change brought in by the commit, with
intelligence, a human may say "G is a completely new file, even
though it shares the leading boilerplate comment with F and every
other file in the project".  Your IDE wouldn't say that.

We designed not to etch such wrong renames/copoies in stone by
recording them at the commit time.  Instead we compare the before
and after image to intuit the _intention_ of what the user wanted to
do _when_ you _ask_ (i.e. when you run "git diff" or "git log").
This has an additional benefit that the heuristics to find out about
renames and copies *can* be improved long after commits are made, so
a commit that used to be misidentified to have renamed a file (when
there is no such renaming) may later say that a file is removed and
a new file is made independently with newer version of Git.