8

I'm running the command git rebase --continue and getting an error:

error: update_ref failed for ref 'refs/heads/HEAD-feature': cannot lock ref 'refs/heads/HEAD-feature': is at db50dd34de1e90c0616bf9318be489ee8d9a012a but expected 83f09532b2352418c0f562f48929dc504e6a0452 error: could not update refs/heads/HEAD-feature

I looked at a couple similar questions but none of the answers worked.

I tried the following:

1. git update-ref -d refs/remotes/origin/HEAD-feature
2. git --no-optional-locks fetch --prune origin
3. git gc --prune=now
4. git remote prune origin

The only way I've found to overcome this is to do git rebase --abort but then I lose all the changes I made during an interactive rebase. Any ideas?

Inigo
  • 12,186
  • 5
  • 41
  • 70
user3492121
  • 535
  • 1
  • 4
  • 12
  • Does this always happen for you when you `git rebase --continue`? Does #1 go well? It comes with some validation. You could try to delete `refs/remotes/origin/HEAD-feature` manually from disk and then `git fetch` again? – zrrbite Dec 06 '21 at 21:37
  • It seems to run fine but then still I still run into an issue with `git rebase --continue` – user3492121 Dec 06 '21 at 21:57
  • Did you try deleting the refs manually (not using git update-ref) and fetching again? – zrrbite Dec 06 '21 at 22:02
  • hm, in my case my ref is only locally available I haven't put it to remote yet. I tried doing `git reset HEAD^` to remove the changes and stash them then `git rebase --continue` but it seems to have the same issue – user3492121 Dec 06 '21 at 22:12
  • Aha, okay. Got confused because your commands involved `origin`. Is the issue only with *this* rebase or is it a general issue? "cannot lock ref" usually means some sort of general corruption of the `.git/refs` folder. – zrrbite Dec 06 '21 at 22:17
  • It seems a general issue when I make a change on this stack of commits I have. It doesn't happen all the time but it does happen multiple times – user3492121 Dec 06 '21 at 22:21
  • The name `HEAD-feature` is a bit weird (why have a branch whose name is mixed case? use all-lower-case to avoid case issues on Windows and macOS) but I suspect the actual problem might be putting a Git repository in a network-drive folder (Google Drive, iCloud, Dropbox, etc). Don't do that. – torek Dec 07 '21 at 03:55

1 Answers1

9

You or some rogue process was messing with your repo state in a way that conflicts with git rebase

The error message indicates that you or someone else or something did something to your repo state, something that you can't do while a rebase is in progress. It was expecting a ref to point to a specific commit, but it got changed out from under it.

How to recover

Here's how to recover from the situation without losing all your rebase work so-far (assuming you haven't yet aborted):

  1. Save your rebase progress so-far

    git branch PARTIAL-REBASE HEAD
    

    This will create a branch ref named PARTIAL-REBASE pointing to the last rebased commit -- i.e. your rebase work so far.

    You must do this before git rebase --abort, otherwise you'll have to search the reflogs to recover your partial rebase, which is more complicated.

  2. Abort the rebase

    git rebase --abort
    
  3. Resume the rebase where it left off

    There are many ways to do this, but this is the easiest.

    First see which commits are included in your saved partial rebase:

    git log PARTIAL-REBASE
    

    Make sure you are on the correct branch, then rerun your original rebase command, but add the following options to the command:

    --onto PARTIAL-REBASE --interactive 
    

    A list of commits to rebase will appear in an editor. Carefully delete only those lines for the commits that are already included in the git log for PARTIAL-REBASE above. DO NOT make any other changes unless you know what you are doing.

    Save and close the rebase list. The commits in the rebase list will now be rebased onto PARTIAL-REBASE, effectively resuming your rebase at the point you aborted it.

  4. Verify and cleanup

    Verify that your rebased branch is good.

    When you're sure that your rebase was successful and all is good, delete the PARTIAL-REBASE ref:

    git branch -D PARTIAL-REBASE
    

See also How to fix "corrupted" interactive rebase? and Git rebase failing, though I'm surprised that no one gave a "How to recover" solution such as mine.

Inigo
  • 12,186
  • 5
  • 41
  • 70
  • From `git branch PARTIAL-REBASE head` I get `fatal: Not a valid object name: 'head'.`(?) Also *look at the history and …* Do I get that from `git log`? – Ole V.V. Aug 31 '22 at 10:47
  • 1
    @OleV.V. I changed step 3 to make it much easier for beginning git users. Please let me know how it goes. – Inigo Aug 31 '22 at 19:02
  • Thanks a lot for reverting on my questions to your answer from last year. *What happens if you run `git log head`?* The answer I get now may not tell anything since I have now aborted the rebase without saving my work and rebased from scratch. In any case I will try when I get to my work computer tomorrow. – Ole V.V. Aug 31 '22 at 19:05
  • *I changed step 3 to make it much easier for beginning git users.* It indeed looks manageable now. :-) – Ole V.V. Aug 31 '22 at 19:07
  • It’s not a problem for me any more, so just in an attempt to reply: even after having aborted and redone the rebase and also pulling, from `git branch PARTIAL-REBASE head` I still get `fatal: Not a valid object name: 'head'.`. However in capitals it worked: `git branch PARTIAL-REBASE HEAD`. – Ole V.V. Sep 01 '22 at 11:05
  • 1
    @OleV.V. Does `git log head` work, or do you also have to type `git log HEAD`? I think I have found the cause: I'll bet you have a case-sensitive file system. https://stackoverflow.com/questions/31102642/are-git-refs-always-case-insensitive. I've update the answer so that it works for such filesystems. – Inigo Sep 01 '22 at 15:36
  • 1
    Yes, I am on Linux, its file names are case sensitive. Thanks for updating. – Ole V.V. Sep 01 '22 at 15:42
  • 1
    `git log head` in lower case gives me `fatal: ambiguous argument 'head': unknown revision or path not in the working tree.`. With upper case `HEAD` it works, gives me the history. – Ole V.V. Sep 02 '22 at 08:46