Re: Bug: git log: boundary commits do not respect order (e.g. date-order, topo-order) 2

I just wanted to follow up -- what do you think?

On Thu, Feb 22, 2018 at 9:21 PM, Josh Tepper [off-list ref] wrote:

My use case is that when combined with --graph, the ordering is
necessary to render a reasonable looking commit graph; by placing the
commits at the end, each boundary commit essentially produces another
vertical line all the way to the bottom where the commits reside.
More specifically, the case where I noticed this was:

git log --boundary --graph ^master feature

which will have one vertical line going all the way to the bottom for
each merge from master into feature.

Another issue that I've noticed is that if one is using
--show-linear-break (instead of --graph), the linear breaks are
missing between the boundary commits and the other commits.

Regarding the documentation, while it doesn't explicitly say where the
boundary commits will be ordered with the other commits (nor does it
say that they'll have accurate linear breaks), the documentation for
the order flags (and for the linear break flag) makes no mention that
certain commits are excluded.  The implicit understanding of the
documentation for --date-order is that it will apply to all of the
commits.  Certainly, if you add the flag --full-history, one expects
the ordering to apply to the additionally traversed commits.  I
suppose boundary commits are a little different since they're not
explicitly part of the range -- nonetheless I expected them to be
treated similarly.

Maybe this could at least be documented?

Best,
~Josh

On Thu, Feb 22, 2018 at 2:29 PM, Derrick Stolee [off-list ref] wrote:

quoted

On 2/21/2018 6:57 PM, Josh Tepper wrote:

quoted

When using git log, boundary commits (ie, those commits added by
specifying --boundary) do not respect the order (e.g., --date-order,
--topo-order).  Consider the following commit history, where number
indicates the order of the commit timestamps:

<view with a fixed with font! 3's ancestor is 1, 6's ancestors are 4,5>
0----1----2----5  <--A
        \         \
          3----4----6  <--B


Executing the following command:

$ git log --boundary --date-order ^A B

Should produce the following order (boundary commits shown with dashes):
6 -5 4 3 -1

However, it in fact produces:
6 4 3 -5 -1

Please advise.

Hi Josh,

Looking at the docs [1], I don't see any specifics on how the boundary
commits should be ordered.

Clearly, the implementation specifies that the boundary is written after all
other commits. For a full discussion of this, see the commit message for
86ab4906a7c "revision walker: Fix --boundary when limited". Here is an
excerpt:

     - After get_revision() finishes giving out all the positive
       commits, if we are doing the boundary processing, we look at
       the parents that we marked as potential boundaries earlier,
       see if they are really boundaries, and give them out.

The boundary commits are correctly sorted by topo-order among themselves as
of commit 4603ec0f960 "get_revision(): honor the topo_order flag for
boundary commits".

So, I'm not sure that this is a bug (it is working "as designed") but it
certainly is non-obvious behavior.

In what use case do you need these boundary commits to appear earlier?

Thanks,
-Stolee

[1] https://git-scm.com/docs/git-log