Junio C Hamano <gitster@xxxxxxxxx> writes: > Ralf Wildenhues <Ralf.Wildenhues@xxxxxx> 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. - 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
