Re: Git log can not show history before rename
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Jan 30, 2009, 17:23 UTC
- Message-ID
- <alpine.LFD.2.00.0901300918010.3150@localhost.localdomain>
- In-Reply-To
- <alpine.LFD.2.00.0901300910580.3150@localhost.localdomain>
On Fri, 30 Jan 2009, Linus Torvalds wrote:
> > If somebody wants to do a more intelligent --follow, I can only applaud, > but I'm personally not likely to look into it.
Side note: you can probably get a _limited_ form of parent rewriting on top of --follow by adding some more hacks. IOW, I think you can make --parents --follow work better in practice even with the hacky thing by adding some more hacks on top. But you'll never get the _true_ answer (ie get things right across renames in different branches) without totally ripping out the current --follow logic.
Interestingly, I suspect that doing --follow "right" is really quite complicated, but one sign of doing it right would be to allow multiple files to be tracked at the same time.
Because in a "correct" implementation of --follow you'd literally have to attach different filenames to different commits (rather than have one global filename that you follow and then switch for everybody when you see a rename), and also have the ability to track multiple files per commit when you reach the same commit under two filenames.
I really never wanted the pain, and never cared enough for it, which is why --follow is such a hack. It literally was designed as a "SVN noob" pleaser, not as a "real git functionality" thing. The idea was that you'd get away from the (broken) mindset of thinking that renames matter in the big picture.
Linus