On Sat, 9 Sep 2006, Marco Costalba wrote:
>
> Sorry, but I don't understand why you should restart the whole thing
> instead of store away the FIXME commit and continue.
>
> If you read my previous e-mail in this thread perhaps it is better
> explained the whole idea.
>
> Anyhow the basic is:
>
> -git-rev-list starts outputting the data early (order is not guaranteed)
>
> -before to mark for output a revision check if it breaks --topo-order
>
> -if the above is true store the revision away and *do not send*
You don't seem to understand.
It's not that individual new commits might be "out of order", and you can
suppress them.
It's that individual commits end up showing that OTHER COMMITS, THAT YOU
HAVE ALREADY SEEN AND SHOWN, can now be shown to be "out of order".
So you're _not_ just suppressing and delaying the few commits that didn't
conform to the topological sorting. What you're asking for is impossible.
You can't just delay those to the end, because they implicitly are telling
you that the earlier commits were already shown in the wrong order.
The example is
A <--- tip of branch
/ \
B E
| |
| F
| /
C
|
D
...
where the lettering is in "date order" (ie "A" is more recent than "B"
etc). In this situation, we'd start following the branch A->B->C->D->..
before we even start looking at E and F, because they all _look_ more
recent.
But then, at some point, we see E and F, and suddenly when looking at F we
realize that C was printed out much much earlier, and was already shown as
having only one child. We can't just say "delay F to the end", because
we'd then have to draw the line _backwards_ to C, which we haven't even
left room for in the graph, not to mention that the end result would look
absolutely disgusting even if we had.
So we started out painting this as
A
/ \
B |
| |
C |
| |
D |
| |
| E
| |
| F
| |
before we notice how wrong it was, and now we have to go _back_, and
repaint both E and F as being above C, because only once we hit F do we
suddenly realize that yeah, it really _was_ younger than C, despite the
timestamp (which was off, because somebody had set his clock to be a week
in the past by mistake).
So we can't just delay F and "fix it up" at the end.
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