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
