CODEWITHSUNDEEP
git
ivallesp
ivallesp

Reputation: 2212

Non consistent git rev-list count

I am working on a zsh custom prompt and I am trying to show how many commits ahead and behind remote my branch is. For that I use the following command

git rev-list --left-right --count main...origin/main

Which returns a b where a are the commits local is ahead of remote, and b are the commits remote is ahead of local.

I have found an inconsistency I cannot properly understand. Reproduction code below

git clone https://github.com/numpy/numpy
cd numpy
git rev-list --left-right --count main...origin/main
#  0     0  # As expected

git reset --hard HEAD~10
git rev-list --left-right --count main...origin/main
#  0     31  # Whaaaaaaat?

Can somebody help me understand what am I missing?

Thanks

Upvotes: 2

Views: 926

Answers (1)

torek
torek

Reputation: 488153

As phd noted in comments, removing one merge commit from reachability by some branch name will generally remove multiple commits from reachability. Given that the numpy repository has a lot of merges on its main branch, the result you saw was unsurprising.

Here is an illustration (not meant to be specific to the numpy repository) where removing one merge commit removes four commits from reachability:

...--G--H------L--M   <-- main (HEAD), origin/main
         \       /
          I--J--K   <-- feature

Branch feature was just merged to branch main (and then pushed), so commits M, L-and-K, J, I, H, G, and so on are all reachable, working backwards, from commit M to which main points.

Making main point directly to L, as we'd get with a git reset --hard HEAD~1, removes commit M from main, but also removes commits I-J-K. So after this reset you'll be "zero ahead" and "four behind" origin/main.

Upvotes: 4

Related Questions