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

[Derrick Stolee <stolee@gmail.com>]

On 2/21/2018 6:57 PM, Josh Tepper wrote:
> 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