Hi, On Tue, 29 Jul 2008, Jeff King wrote: > > Can we please get past this and look at what is required to produce the > > correct history? > > You seem to be indicating here (and elsewhere in the thread) that there > exists some history graph for which neither "git log" nor "git log > --full-history" produces the output you want, but that there is some > better output (even if it might take more time to compute). > > Perhaps I am just slow, but I haven't been able to figure out what that > history is, or what the "correct" output should be. Can you try to state > more clearly what it is you are looking for? Most frequently this involves changes where the same change is merged twice. Another interesting example is kernel/printk.c where a change is added and later removed again before it's merged. With "git-log --full-history" you see these changes, but it lacks the necessary merges to produce a full graph. As consequence none of the graphical front ends produce a useful history graph. This problem now hits me now more seriously in a repository conversion, where it frequently happened, that changes were applied both locally and upstream, so that I have relatively many of these empty merges and the default git-log output is useless. --full-history is more of a workaround than a real solution and again the history graph in _all_ graphical front ends is useless. More generally this means in any kind of situation where you maintain your own repository and it takes a while until upstream accepts your changes, so that you frequently have duplicated changes (because upstream doesn't use git or doesn't pull directly), you have to be careful to get the right history out of git. The point is now that I think the problem is solvable even within Linus' constraints, so that git-log produces the right output by default and a workaround like --full-history isn't needed anymore. 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
