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?


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

Reply via email to