From: Josh Tepper <josh@clarifai.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Bug: git log: boundary commits do not respect order (e.g. date-order, topo-order) 2
Date: Thu, 1 Mar 2018 14:25:40 -0500 [thread overview]
Message-ID: <CAPFeJUDz1GxCUSBzqsNH7wTynbb1Ma03=cOfY0G3frGDCs7H+Q@mail.gmail.com> (raw)
In-Reply-To: <CAPFeJUCkcWMJMt6Eam3NrnYUWXgOS+GB695pzgL+QJsvgOgWWQ@mail.gmail.com>
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
>>
>>
prev parent reply other threads:[~2018-03-01 19:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-21 23:57 Bug: git log: boundary commits do not respect order (e.g. date-order, topo-order) 2 Josh Tepper
2018-02-22 19:29 ` Derrick Stolee
[not found] ` <CAPFeJUCkcWMJMt6Eam3NrnYUWXgOS+GB695pzgL+QJsvgOgWWQ@mail.gmail.com>
2018-03-01 19:25 ` Josh Tepper [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPFeJUDz1GxCUSBzqsNH7wTynbb1Ma03=cOfY0G3frGDCs7H+Q@mail.gmail.com' \
--to=josh@clarifai.com \
--cc=git@vger.kernel.org \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).