Re: Feature Request: git mv --after (new flag)

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

FMorschel <git@fmorschel.dev> writes:

>> But since the decision (of what is related to what) is that this 
>> should mainly be handled by the threshold (so git can figure it out 
>> for you) it's fine then.

The main idea behind the design is that Git can _afford_ to spend
more work at the time of investigating (e.g. when the user asks to
find where this single function came from and the tool answers that
it is the result of consolidating five duplicated functions) than
the time of recording commits (i.e. when it is not yet known what
questions the users will ask about the commit in the future), and
that Git can _improve_ over time how it figures out which removed
ones correspond to which added ones when it is asked to find out
moves and copies, exactly because we do not force people to record
moves at the time of the commit.

It does not preclude a new feature to allow you to tell, say, "git
blame", an extra piece of information to help the command you run,
like, "hey, Git, you may not realize it with the current heuristics
you have, but at commit X, lines N to M of path G was copied to
lines L to K of path F.  You can take that into account when you
figure out where the lines of the current file at path F came from".

You may even store that piece of information alongside commits in a
form that can be transferred across repositories, like notes.  The
important point is to keep such auxiliary pieces of information
outside the commit object, yet allow us to look it up for each
commit.