On Sun, 26 Mar 2006, Petr Baudis wrote: > > My current target is to support this tree (letters are filenames, > numbers are commit ids; I'll translate any git output to those digits): > > 2 4 > b -- d > 1 / \ 6 > a d > \ 3 5 / > c -- d Yeah, the problem with this is that you need to track separate names across separate points. However: > Curiously, git-rev-list does something totally strange when trying to > list per-file history at this point: > > $ git-rev-list HEAD -- d > 4 > > Huh? (It should list 6, 5, 4 instead.) What it does is list the points where file "d" _changed_. "d" did not change in 6 - it had a parent commit (4) where "d" had the same contents (in fact, it likely had _two_ parents where it had the same contents, but git will pick the first one). So commit "6" is uninteresting, and commit "5" will never even be looked at, since we decided that the history of "d" comes from the first parent with the same contents. So then it lists "4", because file "d" really did change in that commit (it went away). Now you need to look at "4" and find the rename (which gives you 2) and then from there you do rename detection and get (1), and as a result your change history should end up being (1)a -> (2)b -> (4)d (-> 6(d) which was your start point) which is correct (now, there are other histories _too_ that get us to the same point, but the one you found this way was _a_ history). > I worked it around by recording a change in d in the merge 6: > > http://pasky.or.cz/~xpasky/renametree2.git/ > > $ git-rev-list --parents --remove-empty HEAD -- d > 6 4 5 > 5 > 4 > > Which is the expected output. No, it's the expected output just because you expected merges to always show up. Merges get ignored if any of the parents have the same content already. Linus - : 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