Hi, On Tue, 29 Jul 2008, Martin Langhoff wrote: > On Tue, Jul 29, 2008 at 2:59 PM, Roman Zippel <zippel@xxxxxxxxxxxxxx> wrote: > > Can we please get past this and look at what is required to produce the > > correct history? > > Roman - correct is --full-history -- any simplification that makes it > easy on your eyes *is* a simplification. And consumers that want to do > nice user-friendly simplification like gitk does can hang off the data > stream. I don't quite understand what you're trying to say. To avoid further confusion it maybe helps to specify a few of the terms: - full history graph: produced by "git-log --full-history --parents" - compact history graph: the full history graph without without any repeated merges, this is what my example script produces. - full simplified history: output of "git-log --full-history" - short simplified history: standard output of "git-log" The important part about the history graphs is that all commits are properly connected in it (i.e. all except the head commit have a child), This is needed to know if you don't just what want to know what happened, but also how it got merged, also any graphical interface needs it to produce a useful history graph. What the short simplified history is more pure laziness, it's fast and gets the most common cases right, but in order to do this it has to ignore part of the history. The full simplified history at least produces produces the full change history, but it lacks part of the merge history and it stills takes longer to generate. The point I'm trying to make is that the compact history graph has the potential to completely replace the simplified history. The only problem is that it needs a bit of cached extra information, then it can be as fast the short simplified history for the common case and it still can produce as much information as the full simplified history, thus you can still apply as much simplification as you want on top of it. Keep in mind that e.g. git-web is using the full simplified history, so what I'm offering also has the potential to improve git-web performance... > > it's also possible to update it when merging/pulling new data. > > If that's what you want to do, you can prototype it with a hook on > fetch and commit. That is definitely an area that hasn't been explored > - what nicer (but expensive) views on the history we have can be > afforded by pre-computing things on fetch and commit hooks. I already did the prototype, I know how to generate that information, the problem is to get that information to the various graphical interfaces. 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
