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

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

[Josh Tepper]

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.

Best,
~Josh

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

[Derrick Stolee]

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

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

[Josh Tepper]

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

On Thu, Feb 22, 2018 at 9:21 PM, Josh Tepper <josh@clarifai.com> 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 <stolee@gmail.com> wrote:
>> 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
>>
>>