CODEWITHSUNDEEP
gitgithub
Goldylox
Goldylox

Reputation: 13

two git branches at same commit, "git log a..b" shows a difference

I have a master and a prod branch that track remotes of the same name and both are the same commit according to git log

picture of git log telling me that they're on the same commit

here's a second picture of github showing me that they're pointing to the same thing

yet, when I type git log prod..master I get a bunch of commits from the last ~week that seems to be in both branches.

if I git branch -vv I can see prod tracking origin/prod, and if i git branch -a | grep prod I get

* prod
remotes/origin/prod

also, when I git checkout prod I get warning: refname 'prod' is ambiguous.

I'm totally stumped about what's happening -- can someone give me a... pointer (sorry).

Upvotes: 1

Views: 597

Answers (2)

torek
torek

Reputation: 488193

If it isn't a tag, it must be some other reference whose priority in the search order "wins" vs a branch name. The gitrevisions documentation provides a six-step process for resolving a symbolic name to a hash ID:

  1. If $GIT_DIR/<refname> exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD);

  2. otherwise, refs/<refname> if it exists;

  3. otherwise, refs/tags/<refname> if it exists;

  4. otherwise, refs/heads/<refname> if it exists;

  5. otherwise, refs/remotes/<refname> if it exists;

  6. otherwise, refs/remotes/<refname>/HEAD if it exists.

When you write git log prod..master, the names prod and master each go through this six-step process. If there is a file in $GIT_DIR named prod that contains a hash ID, step 1 will find that file and use its valule. If not, Git will go on to step 2, to see if refs/prod names a hash ID. If not, Git will go on to step 3 (which tries to resolve prod as a tag name) and if that fails, go on to step 4 (which tries to resolve prod as a branch name).

Given that the git log --oneline image shows that refs/heads/prod does exist, step 4 will definitely succeed, producing the value 9e0ae5792f3c80e76a2b41ed325fa1a20d599a4f (if I transcribed it correctly). So the only way that prod could resolve to a different hash ID is if one of the earlier steps succeeds.

A tag name is the most likely culprit, but your comment implies that there are no tag names: they would show up in git tag --list output. That leaves either step 1 or step 2 as the remaining possibilities.

Note that when you use git checkout, Git doesn't apply the six-step process in that order: first, Git tries to use the name as a branch name. Only if that fails will Git fall back on the six-step process; if that succeeds, git checkout will detach your HEAD, checking out the commit by its hash ID. So that's why you can git checkout prod and get on the branch, even though the reference name is ambiguous (has some meaning in addition to refs/heads/prod).

The command git for-each-ref will print out every reference (everything that steps 2 through 6 could match). It will not check for $GIT_DIR/prod (which step 1 would match), but you can do that yourself by looking inside the .git directory to see if there is a file named prod.

Upvotes: 2

CodeWizard
CodeWizard

Reputation: 142104

Since you mentioned you got a bunch of differences while your git log mark that the local prod and the remote prod branch are the same it looks like you have a tag named prod

if you are not familiar with tags read this answer:
What is git tag, How to create tags & How to checkout git remote tag(s)

In short, use this command to check to see your tags: 

git tag --list

Upvotes: 2

Related Questions