3

I need help with a really exasperating problem. I'm on the dev team for a github repo, and part of that means I frequently review feature updates by contributors from their own forked branches. To do so, I pull down local copies of their repos and checkout specific branches using this code:

git remote add this_fork this_fork_url
git checkout -b this_fork/this_branch
git branch --set-upstream-to=remotes/this_fork/this_branch this_fork/this_branch
git pull

I have local copies of several contributor repos, as well as the origin, among which I switch frequently. With the contributor repos, I never make code changes, I simply review code and compile & test the application.

Yet, I'm noticing that sometimes, when I checkout one of these contributor branches, git will tell me Your branch is a head of remotes/this_fork/this_branch by ## commits. (use "git push" to publish your local commits), or Your branch and 'remotes/this_fork/this_branch' have diverged, and have ## and ## different commits each, respectively. (use "git pull" to merge the remote branch into yours). Since I know I made no changes, I try to soldier on by just running a git pull, but that causes git to force me into a git commit in the former case, and causes git to perform a merge in the latter. Running git status shows the same kind of message, but there are no modified files shown.

Once one of my local copies of the forked repos gets in this situation, the only way I've found to fix it is by entirely deleting the local copy of the repo - but this doesn't always help. I've observed on one branch that it remains in the same situation after I delete it entirely, then re-add the remote (in fact, I deleted the entire director & .git dir with all the local repo copies). Running git reset --hard doesn't help.

This is occurring on both Ubuntu and Windows (the application is cross-platform). Note that this doesn't occur with every remote, every branch, or every time I checkout a branch. I will have no problems with a branch for weeks, then suddenly one day when I check it out, this occurs.

Note that this is not the same as this, in which the author has actually made & pushed changes. In my case, I made no changes.

So I guess my question is two-fold: "Why would git think I've made changes when I have not?" and "How do I fix this?"

Community
  • 1
  • 1
Dr. Andrew
  • 2,532
  • 3
  • 26
  • 42

1 Answers1

3

Try instead git checkout -B this_fork/this_branch remotes/this_fork/this_branch.
As mentioned in the git checkout man page:

If -B is given, is created if it doesn’t exist; otherwise, it is reset. This is the transactional equivalent of

$ git branch -f <branch> [<start point>]
$ git checkout <branch>

That way, you are sure your local branch this_fork/this_branch is always reset to the forked branch remotes/this_fork/this_branch you have fetched.
In that case, there should be no commit ahead or behind.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • `$ git fetch Caritor_Amit howej@Rio-71 MINGW64 ~/KTAB (Caritor_Arun/xmlparser) $ git checkout -B Caritor_Amit/testing Switched to and reset branch 'Caritor_Amit/testing' Your branch and 'remotes/Caritor_Amit/testing' have diverged, and have 36 and 42 different commits each, respectively. (use "git pull" to merge the remote branch into yours)` – Dr. Andrew Jan 01 '17 at 07:26
  • @Dr.Drew what `git checkout -B Caritor_Amit/testing remotes/Caritor_Amit/testing` would return? – VonC Jan 01 '17 at 07:32
  • that seems to have done it. But with one branch, the syntax `git checkout -B this_fork/this_branch` did actually work, while another needed the second. Why would this be? – Dr. Andrew Jan 01 '17 at 07:45
  • @Dr.Drew because (man page) "If `` is not found but there does exist a tracking branch in exactly one remote (call it ``) with a matching name, treat as equivalent to `$ git checkout -b --track /`" – VonC Jan 01 '17 at 07:53
  • @Dr.Drew In your case, it is best to always use the `git checkout -B Caritor_Amit/testing remotes/Caritor_Amit/testing` syntax, as it will always work. – VonC Jan 01 '17 at 07:54
  • thanks, I now understand the difference. The branch for which the simpler syntax worked was an individual (and unique feature branch), while those for which the fuller syntax was required were the `testing` branches, which exist in all remotes. Now, any idea what would cause the problem in the first place - git incorrectly thinking I made changes? – Dr. Andrew Jan 01 '17 at 08:16
  • 1
    @Dr.Drew "any idea what would cause the problem in the first place - git incorrectly thinking I made changes?" that would be the case when Git reuse an existing local branch (`testing`): that is why I recommend `-B`: it forces a branch (even an existing one) to be reset to its remote starting point branch. – VonC Jan 01 '17 at 08:24