Re: Rename handling
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Mar 21, 2007, 00:21 UTC
- Message-ID
- <etptkp$2uo$1@sea.gmane.org>
- In-Reply-To
- <slrnevtdfh.v0v.jgoerzen@katherina.lan.complete.org>
John Goerzen wrote:
Show 20 quoted lines
> I've read the FAQ and Linus' philosophy on this topic, and have some > questions still. I'm considering using Git and its philosophy on > renames is troubling me. > > My use for version control presently has most changes being written and > committed by me directly, with occasional patches coming in from random > others. As such, running something like 'git mv' when a rename occurs > is not a problem. > > My main concerns with Git are: > > 1) git log does not show complete history of files that have been > renamed or copied. > > If I have foo.txt, and rename it to bar.txt, the liberal use of -M > can tease out a proper patch from a number of places. But > git log bar.txt, with any set of options I can possibly come up with, > absolutely refuses to show me the history of bar.txt before it was > renamed to bar.txt. git log foo.txt also does not show me the old > history for the file.
That is because "bar.txt" in "git log bar.txt" is not file name to show history of, but path limiter (BTW. it is not output filter, as it also simplifies history). And you can say for example "git log Documentation/" which I guess is not available in any other SCM beside Git.
There were at least two attempts to provide a kind of --follow=<filename> to the git-log family of commands, to track/show history of a given file across renames. See "Why does git not track renames?" entry in GitFaq (http://git.or.cz/gitwiki/GitFaq) for some history; lately Linus has send prototype of blame engine based implementation of --follow option.
Show 5 quoted lines
> 2) For me, a rename is a logical change to the source tree that I want > to be recorded with absolute certainty, not guessed about later. > Sometimes I may make API changes and it is useful to see how module > names changed, with complete precision, later. I do not want to be > victim to an incorrect guess, which could be possible.
This is much against Git philosophy of "tracking contents", although there was talk allowing recording some optional _helper_ information about file renames, in the proposed 'note' field (header) in commits, but it never materialized.
You can always say that there was rename (or that file was split into two, or that file was refactores) in the commit message.
Besides, the place where you want renames detection to work is during merge. I don't know what would happen if merge base is so far back that git doesn't recognize rename; on the other hand you get huge conflict to resolve anyway.
-- Jakub Narebski Warsaw, Poland ShadeHawk on #git