On Tue, Jul 29, 2008 at 02:32:14PM +0200, Roman Zippel wrote:
> > 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.
I glanced briefly over "gitk kernel/printk.c" and it looks pretty sane.
I was really hoping for you to make your case as something like:
1. here is an ascii diagram of an actual history graph (or a recipe of
git commands for making one)
2. here is what git-log (or gitk) produces for this history by
default; and here is why it is not optimal (presumably some
information it fails to convey)
3. here is what git-log (or gitk) with --full-history produces; and
here is why it is not optimal (presumably because it is too messy)
4. here is what output I would like to see. Bonus points for "and here
is an algorithm that accomplishes it."
> 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.
I think this is a separate issue. Even if you came up with some great
new history simplification, it likely wouldn't become the _default_
right away anyway. So you need to:
1. produce a new simplification algorithm that is at least useful in
_some_ contexts. Then this can be used when desired for those
contexts. It almost doesn't matter how efficient it is, if it is
providing results that are otherwise unavailable. A user can choose
to take the performance hit to get those results.
2. If that algorithm doesn't provide worse output in any other
contexts _and_ it has similar performance to the current default,
then it can be considered for the default.
But I haven't seen convincing evidence leading to step '1', so arguing
about step '2' seems pointless.
-Peff
--
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
