Junio C Hamano wrote: > Petr Baudis <pasky@xxxxxx> writes: > >> An obvious solution would be to have git-diff-tree --follow which >> updates its interesting path set based on seen renames, and now that >> I've written about non-linear history, it's obvious that it's incorrect. >> The other obvious way to go is then to add rename detection support to >> git-rev-list, and it's less obvious that this is a dead end too - I >> didn't inspect the code myself yet, but for now I trust Linus in [2] >> (I didn't quite understand the argument, I guess I need to sleep on it). > > I'd have to sleep on how the core side can help Porcelains, but > I think it is a good thing that you, one of the most vocal > advocate on the list for doing rename recording, are thinking > about this issue and probably would look into rev-list.c soon. > > Looking at the evolution of rev-list.c file itself was a good > exercise to realize that rename tracking (more specifically, > having whatchanged to follow renames) is not such a useful > thing (at least for me). [...] > What this suggests is that switching the set of paths to follow > while traversing ancestry chain needs to depend on which part of > the original file you are interested in. Marking "this commit > renames (or copies) file A to file B" is not that useful -- for > that matter, detecting at runtime like we currently do is not > better either. If a file A and file B were cleaned up and > merged into a single file C, which is in the tip of the tree, > which one you would want whatchanged to switch following depends > on which part of the C you were interested in. > > Unless you are interested in the _entire_ contents of the file, > that is. Then tracking or even recording renames becomes > useful, but that is a special case. > > That is the reason I am not so enthused about recording renames. > I think the time is better spent on enhancing what pickaxe tries > to do (currently it does very little), which I hinted in a > separate message late last night. I think one of the better ideas/suggestions about *recording* filenames was in the "impure renames / history tracking" thread http://marc.theaimsgroup.com/?l=git&m=114122175216489&w=2 <Pine.LNX.4.64.0603011343170.13612@xxxxxxxxxxxxxxx> about adding *auxiliary* (helper) information about renames in commits. I'm not sure about recording parts of the file that were moved or copied. That might have been left for runtime detection in the likes of pickaxe. As it would be helper-only information it would ensure backwards compatibility (older versions would ignore additional information) and forward compatibility (newer version would fallback to current runtime renames tracking/detection). To be generic, I think that the command to record rename/copy or copy'n'paste/cut'n'paste would take set of source files (one or more, unless we want to have an option to mark the file as new supressing any superficial similarities, in which case it would be zero or more), and set of destination files (one or more, with files which were in source repeated it was copy, not repeated if it was rename or cut'n'paste; unless we want to record deletions also, in which case it would be zero or more files). Such information can be I guess easily entered by user... if one remembers to record rename/cut'n'paste/etc. that is. Perhaps if it were a way to easy add such information later, for example confirming detected renames/relationships during merge... It would be much more difficult for user to enter the ranges unassisted. What worries me is that such information, recorded in "own fields to the GIT revision messages" (in commits) can be used only if you track the ancestry; it doesn't help if you have only have two or more revisions and not build relationship graph between them. But maybe I worry unnecessary... BTW. following renames is important not only in examining file [contents] history, in the likes of diff, whatchanged, annotate/blame, pickaxe but also for merges. References: =========== * http://marc.theaimsgroup.com/?l=linux-kernel&m=111314792424707 * http://article.gmane.org/gmane.comp.version-control.git/217 * http://marc.theaimsgroup.com/?l=git&m=114123702826251 * http://marc.theaimsgroup.com/?l=git&m=114315795227271 -- Jakub Narebski Warsaw, Poland - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html