From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: Jeff King <peff@peff.net>
Subject: [BUG?] "error: cache entry has null sha1"
Date: Thu, 31 Oct 2013 10:11:49 -0700 [thread overview]
Message-ID: <xmqqeh719xgq.fsf_-_@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20131031063626.GB5812@sigill.intra.peff.net> (Jeff King's message of "Thu, 31 Oct 2013 02:36:26 -0400")
This is totally unrelated to this thread, but I am seeing a strange
error from the "let's make sure we won't write null sha1" code we
added recently. This reproduces reliably for me, even in a freshly
cloned repository without previous rerere records:
- Check out v1.8.4.1
$ git checkout v1.8.4.1^0
at this point your HEAD should be detached.
- Apply the first patch from this series
$ git am -3 20131031063530.GA5812@sigill.intra.peff.net
- Apply the second patch from this series
$ git am -3 20131031063626.GB5812@sigill.intra.peff.net
Up to this point things should advance smoothly
- Attempt to apply the second patch _again_.
$ git am -3 20131031063626.GB5812@sigill.intra.peff.net
This should detect a no-op, but somehow leaves things in a
conflicted state. I haven't looked into what is wrong, but this
message is not about this failure.
- Try to discard
$ git am --abort
error: cache entry has null sha1: remote-curl.c
fatal: unable to write new index file
This should not happen, no?
"git reset --hard" will remove the funnies, but still...
next prev parent reply other threads:[~2013-10-31 17:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-29 2:36 [PATCH v4] remote-curl: fix large pushes with GSSAPI brian m. carlson
2013-10-30 8:45 ` Jeff King
2013-10-30 22:40 ` brian m. carlson
2013-10-31 6:34 ` Jeff King
2013-10-31 6:35 ` [PATCH 1/3] http: return curl's AUTHAVAIL via slot_results Jeff King
2013-10-31 6:36 ` [PATCH 2/3] remote-curl: pass curl slot_results back through run_slot Jeff King
2013-10-31 17:11 ` Junio C Hamano [this message]
2013-10-31 17:15 ` [BUG?] "error: cache entry has null sha1" Jeff King
2013-10-31 17:21 ` Jeff King
2013-10-31 18:07 ` Junio C Hamano
2013-11-01 22:44 ` Re* " Junio C Hamano
2013-11-01 22:44 ` [PATCH 1/3] unpack-trees: fix "read-tree -u --reset A B" with conflicted index Junio C Hamano
2013-11-01 22:44 ` [PATCH 2/3] t1005: reindent Junio C Hamano
2013-11-01 22:44 ` [PATCH 3/3] t1005: add test for "read-tree --reset -u A B" Junio C Hamano
2013-11-03 8:03 ` Re* [BUG?] "error: cache entry has null sha1" Jeff King
2013-10-31 6:36 ` [PATCH 3/3] remote-curl: fix large pushes with GSSAPI Jeff King
2013-10-31 22:49 ` brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqeh719xgq.fsf_-_@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.