Hi, On Sun, 27 Jul 2008, Linus Torvalds wrote: > You don't actually understand how git works, do you? Probably not and to be honest I don't care, all I want is my history - the correct one. All I know it's in there somehow and all I care is how to get it out of there. Right now you're giving me the choice between a crappy incomplete history or a crappy history full of useless information. That's it? As long as your challenge involves being compared to crappy history, I'm not interested. If the solution should involve a switch "--correct-history" or I have to wait for the result, I don't care, because it's the correct history I want. As long as you're trying to sell me crappy history I'm not buying it. Can we please get past this and look at what is required to produce the correct history? Fact is based on the current git-log output it's simply impossible to produce the correct history without reading the whole history first, since the very last commit can still be relevant for an earlier merge to connect it properly into the graph. This means we need some extra information before even starting to scan through the commits. Luckily this information can be cached once it has been generated and it also can be updated incrementally. E.g. this information could be generated while generating the pack, so you only had to scan the commits which haven't been packed yet, but it's also possible to update it when merging/pulling new data. It's also not much information that is needed, all that is needed is list of commits per file (which are are usually only a few, mostly even none), which git-log can use, so it knows that these are important while scanning the tree. Technically I don't see a really hard problem to implement this, the problem for me is only that I have no idea where to start this within git and how to integrate it. The other problem (over which I have absolutely no control) is whether anyone actually wants to produce a correct history. I hope there is someone, otherwise there would be no need for "git-log --full-history" (which is also used by git-web), this e.g. produces a nice example in kernel/printk.c, where git-web produces two commits (search for tty_write_message), for which none of the front ends can tell me usefully how it fits into the history (they either don't show it at all or it's lost in "gitk --full-history"). bye, Roman -- 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
