On Wed, 18 Jan 2017 10:40:52 +0000 Joao Pinto <Joao.Pinto@xxxxxxxxxxxx> wrote: [...] > I have seen a lot of Linux developers avoid this re-organization > operations because they would lose the renamed file history, because > a new log is created for the new file, even if it is a renamed > version of itself. I am sending you this e-mail to suggest the > creation of a new feature in Git: when renamed, a file or folder > should inherit his parent’s log and a “rename: …” would be > automatically created or have some kind of pointer to its “old” form > to make history analysis easier. Git does not record renames because of its stance that what matters is code _of the whole project_ as opposed to its location in a particular file. Hence with regard to renames Git "works backwards" by detecting them dynamically while traversing the history (such as with `git log` etc). This detection uses certain heuristics which can be controlled with knobs pointed to by Stefan Beller. Still, I welcome you to read the sort-of "reference" post by Linus Torvalds [1] in which he explains the reasoning behind this approach implemented in Git. IMO, understanding the reasoning behind the idea is much better than just mechanically learning how to use it. The whole thread (esp. Torvalds' replies) is worth reading, but that particular mail summarizes the whole thing very well. (The reference link to it used to be [2], but Gmane is not fully recovered to be able to display it.) 1. http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@xxxxxxxxxxxxxxx/ 2. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217