Solved Confusing git log output with revision range

[memreflect]

I thought it would be simple to see the changes between two related branches, but apparently that's not the case here for some reason.

This makes perfect sense to me:

$ git log '--pretty=format:%cs  %h%n' freebsd/stable/13..freebsd/releng/13.0 | tail -n 1
2021-02-04  638e531019f

I requested all commits from releng/13.0, excluding the commits it shares with stable/13, and that's what I got. The last commit listed will be the first commit on the new branch.

However, reversing the range results in confusing output:

$ git log '--pretty=format:%cs  %h%n' freebsd/releng/13.0..freebsd/stable/13 | tail -n 1
2008-02-26  f1ca4da6f79

Given that releng/13.0 branched from stable/13, their commit history should be the same, so that should yield only the changes on the stable/13 branch after releng/13.0 diverged, right? I also double-checked that I'm using .., so it's not a simple matter of .. vs ... unfortunately.

If releng/13.0 branched from stable/13, how is there a commit from the year 2008 in the stable/13 commit history that is not in the releng/13.0 commit history? It would be understandable if it was authored in 2008 and never committed until after releng/13.0 was created, but that does not appear to be the case. Any ideas what I am misunderstanding?

Note that this isn't specifically related to FreeBSD; I'm more interested in improving my understanding of git in this particular instance.

 

[astyle]

One idea that I think may be plausible:

1. When stable/13 branch was created, it retained the commit from 2008.
2. When releng/13 branch was created (presumably branched from stable/13), or some time after, the aforementioned commit was rolled back (or somehow removed) from releng/13's commit history.

Another idea is that reversing the range has reversed the order in which commits are listed. You piped the output to tail -n 1. That 2008 commit very well may be present in both branches. The first code snippet would place that commit at top of the list, while the second code snipped would place it at the bottom (and it would get caught by tail -n 1)

 

[memreflect]

Thank you for your input, but reversing the range doesn't reverse the order. a..b is effectively b AND NOT a. I used tail -n 1 to simplify the output, so I apologize for oversimplifying things. What I'm actually seeing is this:

bash$ git log '--pretty=format:%cs  %h' freebsd/releng/13.0..freebsd/stable/13
2021-09-13  538d7e8b1ac
2021-09-13  61bb00e5283
2021-09-13  04e5691087a
2021-09-13  ae1d4986a52
2021-09-13  b469839bfdd
…
2020-12-30  064c2cf40ea
2020-12-28  808e6812386
2020-12-28  f014700a376
2020-12-28  a0316ad2685
2020-12-28  b6722b871b1
…
2019-12-30  82e996c2616
2019-12-30  8b3438e5034
2019-12-29  153db761979
2019-12-28  2c47bd575a4
2019-12-27  edb24bec3b9
…
…
2010-01-08  694921bc49b
2010-01-08  f7e8739c940
2010-01-08  b520b143059
2010-01-05  5562e5d105a
2010-01-04  82387586af2
…
2009-01-05  b53c565e651
2009-01-05  e9cb2b4f645
2009-01-05  42bcb36c898
2009-01-05  8a2b328b18f
2009-01-05  36b849fa517
…
2008-02-27  f1b59d2620a
2008-02-27  3d4ea0ced6c
2008-02-26  564f6d1509f
2008-02-26  8f48c2c853b
2008-02-26  f1ca4da6f79
bash$ !! | wc -l
git log '--pretty=format:%cs  %h' freebsd/releng/13.0..freebsd/stable/13 | wc -l
    9725

The idea that over 9700 commits are somehow only in stable/13 and not releng/13.0, some even as far back as 2008, seems rather unlikely to me.

 

[astyle]

IIRC, releng/ development is only the polishing for release (and stops with the actual release), while stable/ development continues with the bugfixes until the dev team decides it's time to branch off the next version. This is a conclusion I would take after looking at the Release Schedule.

 

[memreflect]

Thank you for your help, and you're exactly right.

It turns out that many of the commits "missing" in releng/13.0 were done in other branches long ago, and they were only merged into stable/13 after releng/13.0 was already created. This problem was entirely due to my own faulty assumption based on the commit dates, which made me ignore the fact that the branches were not merged until much later. Had I searched for the commit hash when using --graph before today and traced the path to stable/13, this mystery probably would have been solved much sooner. For whatever reason, that idea never occurred to me.

---

My original goal was to see the commits on stable/13 since the releng/13.0 branch was created, but it turns out that wasn't so simple. Here's one way I found to do that:

git log --ancestry-path $(git merge-base freebsd/releng/13.0 freebsd/stable/13)..freebsd/stable/13

I found this Stack Overflow answer to "How does ancestry path work with git log?" rather helpful once I stumbled upon --ancestry-path in git-log(1) since it was not exactly clear to me what effect the flag has.