Re: [PATCH] git-rev-list.txt: rev stands for revision, not reverse.

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 2, 2007, 20:46 UTC
Message-ID: <7v8x5g1ily.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vprys1k5m.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 6 quoted lines

> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>
>> Is the reverse chronological order the primary sorting key at all?
>
> It is mostly chrono but there is a topo element as well.  You
> would never see a parent none of whose child is shown.

To be precise...

Internally, it mainly works on topology with an additional logic to tiebreak with commit timestamps.

 - We always have one or more "output candidates".

 - Initially, the set of output candidates are primed from the
   positive refs (e.g. "foo", foo in "bar..foo", foo and bar in
   "bar...foo") you give to rev-list and/or log family of
   commands, after reachability analysis with negative refs
   (e.g. "^foo", bar in "bar..foo", merge-base of foo and bar in
   "bar...foo") if present.

 - We output the latest one among output candidates.  The
   parents of the commit we output go through the reachability
   analysis and the ones that are reachable from any of the
   negative refs are removed.  The ones that survive this
   reachability analysis are added to the output candidates.
   And the process starts over.  The algorithm terminates when
   there is none.

In practice, because child commits tend to get later commit timestamps than all of their parent commits, the output looks mostly reverse chronological.