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 -- To unsubscribe from this list: 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
