2

I have a git repository which was constructed something like this.

$ git init

After many adds, commits, and furious keyboard-pounding, I am ready to push it to my GitHub repo.

$ git remote add origin git@github.com:me/Foo.git
$ git push -u origin master
Counting objects: 456, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (125/125), done.
remote: error: object c9edb23c0e6c48772785b2a7d89d08c0807b2d4a:contains duplicate file     entries
remote: fatal: Error in object
error: pack-objects died of signal 13
error: failed to push some refs to 'git@github.com:me/Foo.git'

Searching SO, I found the article git tree contains duplicate file entries and followed the instructions there.

$ git ls-tree c9edb > bad_tree.txt

remove duplicate entry (there was only 1!)

$ cat bad_tree.txt | git mktree
8ec5fe5a729ff6f71209cb9a4f75b0059c049190
$ git replace c9edb 8ec5f
$ git fsck --full
Checking object directories: 100% (256/256), done.
error in tree c9edb23c0e6c48772785b2a7d89d08c0807b2d4a: contains duplicate file entries
Checking objects: 100% (457/457), done.

Ok, the article said that fsck will still show the bad tree, but push should now work. Let's fix the signal 13. The SO article Can't push to GitHub error: pack-objects died of signal 13 said it's a file size thing. Ok, let's check this out.

$ git count-objects -v
count: 0
size: 0
in-pack: 457
packs: 1
size-pack: 1910
prune-packable: 0
garbage: 0
size-garbage: 0

Hmm, that's weird. It says it's only 1.9MB. Let's double-check.

$ du -h .git
8.0K    .git/logs/refs/heads
12K     .git/logs/refs
24K     .git/logs
1.9M    .git/objects/pack
8.0K    .git/objects/info
1.9M    .git/objects
44K     .git/hooks
4.0K    .git/branches
12K     .git/info
4.0K    .git/refs/heads
4.0K    .git/refs/tags
4.0K    .git/refs/replace
16K     .git/refs
2.1M    .git

Ok, something is crazy. Git and the filesystem agree that the whole repository is only ~2MB, but I'm getting signal-13 on push. Hmm. Let's try it again.

$ git push -u origin master
Counting objects: 456, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (125/125), done.
remote: error: object c9edb23c0e6c48772785b2a7d89d08c0807b2d4a:contains duplicate file     entries
remote: fatal: Error in object
fatal: The remote end hung up unexpectedly
error: pack-objects died of signal 13
error: failed to push some refs to 'git@github.com:me/Foo.git'

Grr. The "content manager from hell", indeed. Is my repo just knackered? Is there any possibility of pushing only the last commit to github without the history? (and prefereably without making my local repo a remote of another local repo and copy-pastaing the whole thing over).

Community
  • 1
  • 1
Tim
  • 1,517
  • 1
  • 9
  • 15
  • 1
    So I'm technically not supposed to say something like this because it doesn't really add to the question itself, but `+1` for doing a great job of doing your own research first, and giving a detailed explanation of what you have already tried. –  May 20 '14 at 23:35
  • I can't find where in the linked articles says you can push a bad history, and the [git replace docs](https://www.kernel.org/pub/software/scm/git/docs/git-replace.html#_description) say it won't work for pack transfer (packs being the output of `pack-objects`). – jthill May 21 '14 at 01:22
  • @jthill, you are quite right. I didn't see that in the docs page. It also seems there is a bug in filter-branch (either in the code or in the docs) as the docs say that filter-branch will make all ref replacements permanent, but it doesn't. – Tim May 22 '14 at 21:53
  • @Cupcake, thanks! I was just trying to make it readable and quickly understandable. – Tim May 22 '14 at 21:54
  • @Tim you know you can answer your own question, right? –  May 22 '14 at 22:14
  • @Cupcake, I did not know that. Perchance if I had read the giant button that says "Answer This Question," I might have known that. ;) – Tim May 22 '14 at 22:31

2 Answers2

1

Rather serendipitously, I happen to be reading the O'Reilly Git book and found a neat little trick using git branch-filter. I should note that the duplicate entry error was due to a subfolder being added to the index both as a directory and as a symlink in a single commit (I won't be doing that again!).

$ git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch src/dupe' master

Even though we've just nuked that subdirectory from orbit, the bad blob is still in the repo.

$ git fsck
Checking object directories: 100% (256/256), done.
error in tree c9edb23c0e6c48772785b2a7d89d08c0807b2d4a: contains duplicate file entries
Checking objects: 100% (457/457), done.

It looks like git doesn't want to give up that blob! That's an easy fix. Dangling blobs are (most safely) dealt with by just cloning the repo.

$ cd ~/Foo_new
$ git clone --no-hardlinks file://~/Foo

The --no-hardlinks option prevents git from optimizing the clone using hardlinks and ensures that the cloned repo contains copies of everything from the old repo so you can delete the old repo safely. A quick check shows everything is in working order now.

$ git fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (433/433), done.

Now I need to reset my remotes since this is a cloned repo.

$ git remote set-url origin git@github.com:me/Foo.git

And push to github.

$ git push origin master
Counting objects: 433, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (115/115), done.
Writing objects: 100% (433/433), 471.04 KiB | 0 bytes/s, done.
Total 433 (delta 318), reused 433 (delta 318)
To git@github.com:me/Foo.git
 * [new branch]      master -> master

Success!

Tim
  • 1,517
  • 1
  • 9
  • 15
1

I also ran into the same issue today and after trying lots of the above I ended up not 'caring' about the history as such and instead decided to squash the history into one commit.

eg situation at hand:

  • branch master broken;
    • error 13 when trying to push
    • this happened around 10-15 commits back
  • branch origin/master unable to receive the new update

I then performed the following simple steps:

  • git checkout master
  • git branch master_maintained_for_old_history
  • git reset origin/master --soft
  • git commit -a -m 'a single squash commit ...'
  • git push -u origin master -f

When trying to do an interactive rebase, this failed as it was still trying to 're-use' the existing 'broken' commits to replay, thereby causing the issue to happen again. This solution of simply ditching all that broken history and having a single commit was the cleanest for me in the end.

Cheers, Rob

fuzzyrob
  • 31
  • 3