“Index-pack failed”

Question

upon cloning a git repository, I get an error message that I can\'t quite grasp.

$ git clone git@pinocchio.unibe.ch:group07
Initialized empty Git repository         


        

Answer 1

Is this similar to ticket 269?

git index-pack isn't a built-in in git.exe, so git.exe needs to find git-index-pack.exe in $GIT_EXEC_PATH (which should usually be "/libexec/git-core/"). Do you have "/libexec/git-core/git-index-pack.exe"?

Because if it is, this is the server which causes the error, not the locally installed git doing the push.

You can try logging interactively and check index-pack is available:

$ ssh git#***.com@***.com
Enter passphrase for key '/c/Users/***/.ssh/id_rsa':
Last login: Tue Feb  9 13:48:32 2010 from ***
-bash-3.2$ git version
git version 1.6.1
-bash-3.2$ git-index-pack
usage: git index-pack [-v] [-o ] [{ ---keep | --keep= }] [--strict] 
{  | --stdin [--fix-thin] [] }

That test prompted the following answer:

Your git-index-pack is found when logging in interactively.
But apparently not when you do not log in interactively.
That suggests that you adjusted your PATH appropriately in $HOME/.profile or $HOME/.bash_profile, but not in HOME/.bashrc

And the conclusion:

My solution is:

ssh user@server
cp .bash_profile .bashrc

---

Note that with Git 2.25.2 (March 2020), the index-pack code now diagnoses a bad input packstream that records the same object twice when it is used as delta base; the code used to declare a software bug when encountering such an input, but it is an input error.

See commit a217810 (03 Feb 2020) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 7b029eb, 14 Feb 2020)}

index-pack: downgrade twice-resolved REF_DELTA to die()

^{Signed-off-by: Jeff King}

When we're resolving a REF_DELTA, we compare-and-swap its type from REF_DELTA to whatever real type the base object has, as discussed in ab791dd138 ("index-pack: fix race condition with duplicate bases", 2014-08-29, Git v2.2.0-rc0 -- merge).
If the old type wasn't a REF_DELTA, we consider that a BUG(). But as discussed in that commit, we might see this case whenever we try to resolve an object twice, which may happen because we have multiple copies of the base object.

So this isn't a bug at all, but rather a sign that the input pack is broken. And indeed, this case is triggered already in t5309.5 and t5309.6, which create packs with delta cycles and duplicate bases. But we never noticed because those tests are marked expect_failure.

Those tests were added by b2ef3d9ebb ("test index-pack on packs with recoverable delta cycles", 2013-08-23, Git v1.8.5-rc0 -- merge listed in batch #4), which was leaving the door open for cases that we theoretically could handle.
And when we see an already-resolved object like this, in theory we could keep going after confirming that the previously resolved child->real_type matches base->obj->real_type.

But:

• enforcing the "only resolve once" rule here saves us from an infinite loop in other parts of the code.
  If we keep going, then the delta cycle in t5309.5 causes us to loop infinitely, as find_ref_delta_children() doesn't realize which objects have already been resolved.
  So there would be more changes needed to make this case work, and in the meantime we'd be worse off.

• any pack that triggers this is broken anyway.
  It either has a duplicate base object, or it has a cycle which causes us to bring in a duplicate via --fix-thin.
  In either case, we'd end up rejecting the pack in write_idx_file(), which also detects duplicates.

So the tests have little value in documenting what we could be doing (and have been neglected for 6+ years).
Let's switch them to confirming that we handle this case cleanly (and switch out the BUG() for a more informative die() so that we do so).