I just wanted to follow up -- what do you think?
On Thu, Feb 22, 2018 at 9:21 PM, Josh Tepper <j...@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 <sto...@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 >> >>
