FMorschel <git@xxxxxxxxxxxxx> 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.
