Dear diary, on Sun, Mar 26, 2006 at 06:33:13PM CEST, I got a letter
where Linus Torvalds <torvalds@xxxxxxxx> said that...
> If you do
>
> git-rev-list --parents --remove-empty $REV -- $filename
>
> then you'll get the whole history for that filename. When it ends, you
> know the file went away, and then you do basically _one_ "where the hell
> did it go" thing.
>
> And yes, it's not git-ls-tree (unless you only want to follow pure
> renames), it's actually one "git-diff-tree -M $lastrev". Then you just
> continue with the new filename (and do another "git-rev-list" until you
> hit the next rename).
I wrote a long rant but then it all suddenly fit together and I have now
an idea how to implement it reasonably elegantly.
So only a bugreport remains:
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
With the commits created in the numerical order (so log shows
1,2,3,4,5,6, and my target is cg-log d showing the same output). If
anyone wants the sample history, it's at
http://pasky.or.cz/~xpasky/renametree1.git/
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.)
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.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
-
: 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