Commits ahead by N but no differences

When I display my branches in the GitLab UI, it displays information about the commits ahead/behind against master for each branch. I have a branch (X) which is claimed to be 23 commits ahead of (I assume) master, however when I do a comparison it shows no differences. Further, when a merge request is created, it wants to create the request in WIP mode because there are no pending changed between the X branch and master.

When I display the branch graph, it correctly shows that X had merged into master at the top of the tree.

What am I doing wrong here? Is it possible that somehow 23 commits were missed in the X -> master merge? (but if so, how would it determine X is still ahead by 23 commits?)


Sorry, I don’t know how to help, but I’m curious …

What does git log look like for each branch? Was any rebasing or squashing performed?

No squashing was performed. I don’t believe I did any rebasing, but the branch is old (since Nov 2018) so it’s possible somewhere along the way something was rebased. Otherwise, the git log looks like what I’d expect it to look like, the list of commits and merges that I’ve actually done (in other words, looks correct to me, nothing really stands out as “wrong”)

I’ve done a few more commits into the X branch and merges from X into master. Still X is 23 commits ahead.

Again, just wondering here … about branch/revision symmetric differences.

Locally, i.e., full repo pulled, etc., … what does git log X...master and git log master...X show?

Ah I gotcha.I didn’t think of the comparison. So I’ve made changes since I last posted (progress waits for no one!)… at the moment, gitlab says branch X is 23 commits ahead.

When I run git log X...master (3 dots) I see 6 commits, both merges from the X into the master and then the 4 commits I’ve put on the X branch recently.
git log master...X (3 dots) produces exactly the same output

When I run git log master..X (2 dots) I see the changes I’ve recently made on X (4 commits total) and X..master (2 dots) shows just the two merges from X into master.

By my count. X should only be 4 commits ahead. It’s interesting that adding commits to X does not increase the commits ahead count.

I get similar results when running against the origin/ references of those branches. Is this what you were wanting to see, or am I just completely blowing it here?

Interesting. I’m beginning to wonder how the counting works for ahead/behind.

it feels like something is stuck. I can try exceeding 23 commits and seeing if that unsticks it (aka hit it with a hammer method)
I can always just nuke the branch. My main concern was that there were 23 commits in limbo somewhere. But functionally in the product and code-wise I don’t see anything missing… so this could be an instrumentation issue. Do you think it worthy of a defect report at this point (just looking for a second opinion)

If a minimal working example of the issue could be created, that would definitely help the developers. Otherwise, I’m not sure.