80

I have a fork of a Git repo and my clone appears to have an issue with an old, no longer existant, branch. I keep seeing this message:

error: refs/heads/t_1140 does not point to a valid object!

I don't have any other messages and the repo works fine. There's no operation that stops me from working on other branches, pushing changes, pulling...etc.

I've looked around and there's less than clear instructions on how to get around this issue. I've tried to execute git fsck --full but I see no errors. Just a load on dangling ... messages.

I've also checked my .git/config and there's no references to this branch and have also checked .git/refs/heads and there's no reference to t_1140

Any idea how to get rid of this error?

p.s I've tried to clone my repo again and it seems like the error is my Github repo too. So, the only thing I can think of right now is to ditch my repo and fork again.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
Galder Zamarreño
  • 5,027
  • 2
  • 26
  • 34
  • By the way, I'm getting this error while for example, pushing master `git push origin master` and I know for sure I'm in master: – Galder Zamarreño Jun 07 '11 at 13:28
  • This is getting worse, it now affects my newly created branches too as shown in https://gist.github.com/1012439. After pushing the newly created `t_1144` branch, I suddenly get error messages for this branch anytime I try to push another branch. And from that point, any try to sync up with an upstream repo shows that error and the `t_1140` ones: https://gist.github.com/1012452 – Galder Zamarreño Jun 07 '11 at 15:20
  • I've wiped out my fork and forked again. It all looks good now. – Galder Zamarreño Jun 08 '11 at 08:26
  • Possibly related: https://stackoverflow.com/q/20663239/5419599 – Wildcard Jul 22 '17 at 02:19

15 Answers15

56

This will clean out any missing refs:

git for-each-ref --format="%(refname)" | while read ref; do
    git show-ref --quiet --verify $ref 2>/dev/null || git update-ref -d $ref
done
Tor Arne
  • 721
  • 6
  • 11
  • 4
    This safely deletes the local ref without doing any destructive operation on the remote. Removing the `--quiet` flag and `2>/dev/null` for verbose output also helps. – akhan Jun 17 '20 at 20:59
37

Check .git/refs/remotes/origin. They are there and the upstream no longer has them. To clean out the remotes that no longer exist run

git remote prune origin

You could also see what it would to by adding --dry-run before actually doing it.

Drew Gaynor
  • 8,292
  • 5
  • 40
  • 53
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 1
    Hmmm, that did not work. I see no reference to t_1140 there and I still have the same error. Thanks for help! – Galder Zamarreño Jun 08 '11 at 07:46
  • @GalderZamarreño: What does `git show-ref` show? The branch ref may have been packed and won't necessarily correspond to a file under `.git/refs`. – CB Bailey Jun 11 '11 at 11:39
  • 6
    The prune didn't work for me either. What I did was navigating to the specified folder ".git/refs/remotes/origin" and then I simply deleted the file matching my error message. That made the error go away. – CowboyBebop Jul 11 '18 at 16:39
  • 1
    This does not solve the OP's problem. See http://stackoverflow.com/a/59162332/2761869 – Tor Arne Dec 07 '19 at 13:34
28

I run into this error on a regular basis. git remote prune origin does not work for me.

[ Update. AFAIU, I'm running into this problem because of using git alternate. Say I've got repo A, registered as alternate for repo B. When I create a new branch br in repo A, and fetch repo A as remote in repo B, git will create a remote ref .git/refs/remotes/A/br for the new branch. When I delete the branch in repo A, and after the corresponding object is garbage-collected, I get the 'error: refs/remotes/A/br does not point to a valid object!' ]

I've written this script (updated to deal with packed refs) to remove the dangling refs (using the info in Validate if commit exists).

#!/bin/sh

set -e

if [ $# -eq 0 ]; then
    dir="."
else
    dir="$1"
fi

if [ ! -d "$dir" ]; then
    echo "not a dir: $dir"
    exit 1
fi

if [ ! -d "$dir/.git" ]; then
    echo "not a git repo: $dir"
    exit 1
fi

cd "$dir"

files=$(find .git/refs -type f)

for f in $files; do
    id=$(cat "$f")
    if ! git rev-parse --quiet "$id" \
    >/dev/null 2>&1; then
    continue
    fi
    if ! git rev-parse --quiet --verify "$id^{commit}" \
    >/dev/null 2>&1; then
    echo "Removing ref $f with missing commit $id"
    rm "$f"
    fi
done

if [ ! -f .git/packed-refs ]; then
    exit 0
fi

packfiles=$(cat .git/packed-refs \
    | grep -v '#' \
    | awk '{print $2}')

for f in $packfiles; do
    if ! git rev-parse --quiet --verify "$f" \
    >/dev/null 2>&1; then
    continue
    fi
    id=$(git rev-parse "$f")
    if ! git rev-parse --quiet --verify "$id" \
    >/dev/null 2>&1; then
    continue
    fi
    if ! git rev-parse --quiet --verify "$id^{commit}" \
    >/dev/null 2>&1; then
    echo "Removing packed ref $f with missing commit $id"
    git update-ref -d $f
    fi
done
Community
  • 1
  • 1
TdV
  • 381
  • 3
  • 3
  • This script solved it for me. In my case I was using `git clone --reference path/to/existing/clone.git git@github.com:remote-repo` to re-use already existing local clone over a slow connection when cloning the same repository multiple times. Probably some refs got deleted in one clone and the other did not know about it. – stefanfoulis Jul 23 '19 at 08:21
  • See https://stackoverflow.com/a/59162332/2761869 for a git one-liner that does the same. – Tor Arne Dec 03 '19 at 17:21
  • I face this issue because I accidentally disconnected the hard drive from my laptop. This script solved the issue. Thank you! – Dmitry Grinko Mar 16 '20 at 07:00
16

Your local clone is probably fine, the problem is that the t_1140 branch objects are missing from your GitHub repository.

I had this problem too and GitHub support fixed it, I think by deleting refs/heads/t_1140 on their end.

Update: I got the error again with another branch and I was able to fix it by running this command:

git push origin :refs/heads/t_ispn982_master

You should get a warning message like this:

remote: warning: Allowing deletion of corrupt ref.

but the corrupted branch will be deleted

Dan Berindei
  • 7,054
  • 3
  • 41
  • 48
5
error: refs/heads/t_1140 does not point to a valid object!

So let's say you've tried pruning with this:

git remote prune origin

and you still CAN'T GET IT TO WORK, as a last resort, try deleting t_1140

Basically,

1. cd refs/heads

2. rm -r t_1140

jaisonDavis
  • 1,407
  • 2
  • 22
  • 36
3

I had this issue when attempting to clone some github repositories, the system I was on was running an older version of git v1.7.4, a quick update fixed it up.

remote: Counting objects: 533, done.
remote: Compressing objects: 100% (248/248), done.
remote: Total 533 (delta 232), reused 529 (delta 230)
Receiving objects: 100% (533/533), 121.36 KiB, done.
Resolving deltas: 100% (232/232), done.
error: refs/remotes/origin/master does not point to a valid object!
verror: Trying to write ref refs/heads/master with nonexistant object 0457f3e2e9432e07a1005f0f4161dc4b8215f128
fatal: Cannot update the ref 'HEAD'.
codemonkee
  • 2,881
  • 1
  • 25
  • 32
  • How is this relevant? – Buffalo Aug 11 '17 at 12:26
  • How is it not relevant @Buffalo ? "_I had this issue_" referring to the OP's question and my output shows the same error message the OP refers to "_does not point to a valid object!_", my resolution was to update the Git binary. – codemonkee Aug 14 '17 at 15:59
  • I had this issue in AWS CodeBuild: changing image from `aws/codebuild/standard:4.0` to `aws/codebuild/standard:5.0` resolved it (Ubuntu 18.04 to 20.04). – Morgan Christiansson Sep 15 '21 at 15:49
3

You say that you have:

also checked .git/refs/heads and there's no reference to t_1140

... which is very surprising. I can only see how this error would occur if the file .git/refs/heads/t_1140 exists. Is it possible you were mistaken about this?

Correction: Charles Bailey points out below that the refs might be packed, in which case there is no corresponding file in .git/refs/heads

Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • 1
    You should never assume that all refs corresponded to files in `.git/refs` as they may have been packed. It is much better to use `git show-ref` which will show packed and unpacked refs. – CB Bailey Jun 11 '11 at 11:36
  • @Charles Bailey: thanks for the correction, I'd quite forgotten about packed refs. I'll leave this undeleted anyway in case it's helpful to someone else making the same mistake. – Mark Longair Jun 20 '11 at 08:58
2

If it's failing with this:

error: failed to run repack

Look in .git/packed-refs for the listed branch(es) and remove those lines. I tried all the other solutions, but this finally solved it for me.

Tarka
  • 4,041
  • 2
  • 22
  • 33
  • Yes I think this is the actual answer to the question. Remove the sha1 from packed-refs or if you feel brake remove .git/packed-refs entirely. It will require a git fetch after this step. – ndoc Jun 22 '20 at 16:17
2

Had this issue after rewriting the history and deleting many branches at the same time.

rm -rf .git/refs/remotes/origin/
git fetch

solves the issue by removing all remote references, and fetching them again.

Stefano
  • 1,686
  • 1
  • 16
  • 25
1

Do a text search through your .git directory for your branch

Use something like grep or findstr and remove all instances.

Cordell
  • 1,901
  • 1
  • 13
  • 12
0

This fixed it for me:

git push origin :refs/remotes/origin/[branch name]
git push origin :refs/heads/origin/[branch name]

WARNING: this deletes the branch from the server - any changes on that branch that have not been merged to another branch will be lost.

Frank Forte
  • 2,031
  • 20
  • 19
0

I had this problem and none of the remedies suggested above worked. So I edited .git/packed-refs and removed the line that mentioned the non-existent branch. All was suddenly well.

Gotta love those human-readable file formats ...

Eddy
  • 11
  • 1
0

After trying various solutions, I finally got the references cleaned up on Windows command prompt with the following:

for /f %i in ('git for-each-ref --format="%(refname)"') do git show-ref --quiet --verify %i || git update-ref -d %i
Azametzin
  • 5,223
  • 12
  • 28
  • 46
user13263866
  • 1
0

Apart from what others have mentioned, this issue can occur if you have some problem with git mirrors which you are currently using, try using other mirror images available.

  1. Get the working mirrors link
  2. Remove the existing one which is having issue

git remote -v

git remove remote origin

  1. update with working one.
git remote add origin <New mirror URL>
Achal
  • 11,821
  • 2
  • 15
  • 37
-1

I'm giving my two cents for whoever is using Visual Studio. I had this issue while trying to delete a local branch and running the following command through the command line solved it:

git branch -D <branchName>
Mari Faleiros
  • 898
  • 9
  • 24