have to pull twice to update a work branch

[fedher]

Hi,

I'm using bash in my terminals and I face very often a weird issue that happens when I change to another work branch and make a pull. The first time the pull fails showing the error message below. The second time works fine.

• First pull

$ git checkout devel

$ (𝘮 ← 272 devel) 2A git pull
Ubuntu 13.10 ssh-pty

error: Ref refs/remotes/origin/devel is at 8d5945183d93bb831fc58f71b0801b97fbb2076f but expected 91981363fc49ccc92b7519695f08e7c9e41ec181
From xxxxxx:proyect/app
 ! 9198136..8d59451  devel -> origin/devel  (unable to update local ref)

• Second pull

$ (𝘮 ← 274 devel 2↓) 2A git pull
Ubuntu 13.10 ssh-pty

Updating 9198136..8d59451
Fast-forward
...

Can anybody point me out in the right direction about what the problem is? Thanks.

[hallzy]

Have you checked stack overflow? I found this which looks like a similar problem to yours.

Is this problem specific to git-radar? Because It appears that similar error occurs without it.

I have not had this problem ever, and not with git-radar either.

[fedher]

I'll check it out. It seems a problem related to git-radar, without it works well. Thanks for the quick response.

[hallzy]

hmm... I'll keep an eye out. I will come back here if I find anything.

[lucascaton]

I'm having exactly the same problem here.

[michaeldfallen]

@lucascaton are you getting the same Ref refs/remotes/origin/<branch> is at foo but expected bar message? Suggests that the background fetch isn't working correctly.

[lucascaton]

@michaeldfallen I guess the background fetch is working well - I can see the arrows icons changing automatically from time to time:

I tested about 10 times right now with different repos, it looks like the problem doesn't happen anymore! 😄

[lucascaton]

Well, it just happened again 😞

$ git pull --rebase

error: cannot lock ref 'refs/remotes/origin/master': ref refs/remotes/origin/master is at 65735d3e448b88a9ca7e09596579090d7466deb7 but expected 97dbc8873fa32a83c17378628d072cd52c35dec6
From github.com:foo/bar
 ! 97dbc88..65735d3  master     -> origin/master  (unable to update local ref)
error: cannot lock ref 'refs/remotes/origin/branch1': ref refs/remotes/origin/branch1 is at 1e6b13817159a8087454aa7d10415c9ed9174629 but expected 0322ea944c7460a8751fa87df2f95a4e48b24c44
 ! 0322ea9..1e6b138  branch1 -> origin/branch1  (unable to update local ref)
error: cannot lock ref 'refs/remotes/origin/branch2': ref refs/remotes/origin/branch2 is at 2465da7a5d5943f47177b55846dbb46e8b74d720 but expected 0622a9c2f945751cfb91887456153a13b7ffc499
 ! 0622a9c..2465da7  branch2    -> origin/branch2  (unable to update local ref)

[hallzy]

Is there any kind of reproducible pattern that you have noticed? I have been unable to reproduce this problem at all.

[lucascaton]

--rebase maybe?

[hallzy]

I use --rebase and I have not seen this problem with that command. I have found these which show similar issues:

http://stackoverflow.com/questions/12416643/notorious-git-error-remote-rejected-failed-to-lock

http://emacs-devel.gnu.narkive.com/YJDjId4U/git-error-on-master

Maybe these will help. I will see if I can reproduce the problem and come back if I find anything.

Out of curiosity, what version of git are you using?

[hallzy]

I've noticed this can also sometimes happen if you are working with someone that has modified the git history that has already been pushed. Perhaps this is the case?

http://stackoverflow.com/questions/19548199/git-reference-conflicts-between-branches-unable-to-update-local-branch

The comments of the question above says some about this.

Maybe every once in a while check the log of your local rep and compare it to the remote and see if a commit has been added to the middle or a commit in the middle has been changed in some way

[lucascaton]

This isn't my case, no one changes the git history (by using git push --force for example).

Also, not sure if it helps, but here are my dotfiles: https://github.com/lucascaton/dotfiles.

[fedher]

I've seen this problem when I have to switch to another branch whose origin has been updated by someone else, so my local copy is some commits behind the origin. I change to that branch, I run a "git pull" and I see the error message. Then, when I run "git pull" for the second time, everything works well.

Besides that, sometimes, the first time I move to another branch I don't see the git prompt info regarding to the number of commits to download, I can see that info after the first "git pull" that shows the error message.

[michaeldfallen]

Ok, This just happened to me and I think I have an idea of what's going on.

Steps to reproduce:

1. Wait until after the 5 minute fetch time limit
2. Have someone else update a branch on the remote (push new commits for example)
3. Hit enter (triggering a fetch in the background)
4. run git pull quickly
5. error: cannot lock ref 'refs/remotes/origin/master': ref refs/remotes/origin/master is at 7e7a2e551538f12fe8fe843a32f764e23075651e but expected c8599fadc27e88032933ab9ff0b4b44f88e662f6

Theory:
When you hit enter it triggers a fetch. The file .git/refs/remote/origin/master is locked by the background fetch job. When you git pull it can't update the ref because it's currently locked. Once that first pull fails the fetch has succeeded by then and the second pull passes just fine.

[fedher]

Thanks Michael, this makes more sense now.

[fedher]

Please, let me know If anyone comes up with a workaround.
Thanks,

[lucascaton]

Any news on this one?

[lucascaton]

BTW, my temporary workaround is an alias that runs it twice:
https://github.com/lucascaton/dotfiles/blob/master/files/zshrc#L67

[lucascaton]

I've fixed this problem by replacing git-radar with gitHUD.

[hallzy]

I haven't had a chance to look into this for a while, but I do have a (probably) better workaround.

in the git-radar script if we do:

  if [[ "$command" == "--fetch" ]]; then
    his=$(cat ~/.bash_history | tail -n1)
    if [[ "$his" != *"git pull"* && "$his" != *"git fetch"* ]]; then
      nohup $dot/fetch.sh >/dev/null 2>&1 &
    else
      echo " " >> ~/.bash_history
    fi
  fi

This stops the fetch function of git radar from running when the user runs git pull or git fetches. The echo in the else pushes an empty line on the bottom of the history file. Unfortunately without doing this, if I enter a git pull command, and then just press enter at the prompt without typing anything the script would still think you entered a git pull command. I could not think of a better way to do this

I would push a pull request for this, but it still has some issues. The above issue being one of them.

The second is, (assuming you use bash) you need to add these two lines to your bashrc:

shopt -s histappend
PROMPT_COMMAND="history -a;$PROMPT_COMMAND"

The first line says to append to the bash_history file. The history -a in the second line forces the last entered command into the history file. I put it in PROMPT_COMMAND because the commands inside this variable are executed every time the prompt is written.

The other issue is that I don't know how this will (or will not) work for other shells, since I don't use any other shell. ie. the script currently expects that you are using bash, and that your bash_history file is in ~/.bash_history.

I tried using $HISTFILE instead, but that seems to hang the script for some reason.

I could also require everyone to export a variable in their bashrc for the location of the history file, but that is just more configurations that we probably don't want.

Assuming however that you do not mind having blank spaces added to the bottom of your history file, or you do not mind adding some lines to your bashrc, this does actually seem to work.

@michaeldfallen if you would accept this in some way (making it an optional feature, giving instructions about how to do this in the readme, including a variable in the bashrc to point at the history file etc) let me know, and I can definitely do that

[tuminoid]

This issue occurs when git-radar is doing a fetch in background and user runs git fetch/pull. Git has index.lock to lock index during a fetch, so you cannot corrupt the index by doing concurrent fetches. Your git command fails because of this lock prevents git modifying index.

What git-radar should do, is check for the lock file and wait until it is gone before doing a fetch.

[liudonghua123]

I have this issue too.