Re: [PATCH 2/3] do not write null sha1s to on-disk index
From: Jeff King <hidden>
Date: 2016-06-15 22:55:37
On Sat, Dec 29, 2012 at 02:03:46AM -0800, Jonathan Nieder wrote:
quoted
--- a/read-cache.c +++ b/read-cache.c@@ -1800,6 +1800,8 @@ int write_index(struct index_state *istate, int newfd) continue; if (!ce_uptodate(ce) && is_racy_timestamp(istate, ce)) ce_smudge_racily_clean_entry(ce); + if (is_null_sha1(ce->sha1)) + return error("cache entry has null sha1: %s", ce->name); if (ce_write_entry(&c, newfd, ce, previous_name) < 0) return -1;Quick heads up: this is tripping for me in the "git am --abort" codepath:
Thanks. The intent was that this should never happen, and we are protecting against bogus sha1s slipping into the index. So either we have found a bug in "am --abort", or the assumption that it should never happen was wrong. :)
$ cd ~/src/linux $ git checkout v3.2.35 $ git am -3sc /tmp/alsa-usb-audio-fix-missing-autopm-for-midi-input.patch Applying: ALSA: usb-audio: Fix missing autopm for MIDI input Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... error: Your local changes to the following files would be overwritten by merge: sound/usb/midi.c Please, commit your changes or stash them before you can merge. Aborting Failed to merge in the changes. Patch failed at 0001 ALSA: usb-audio: Fix missing autopm for MIDI input When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". $ git am --abort error: cache entry has null sha1: sound/usb/midi.c fatal: unable to write new index file Unstaged changes after reset: M sound/usb/midi.c $
I can't reproduce here. I can checkout v3.2.35, and I guess that the patch you are applying comes from f5f1654, but I don't know your local modification to sound/usb/midi.c. If I just make a fake modification, I get this: $ git checkout v3.2.35 $ echo fake >sound/usb/midi.c $ git format-patch --stdout -1 f5f1654 | git am -3 ~/patch [same errors as you] $ git am --abort Unstaged changes after reset: M sound/usb/midi.c So I wonder if there is something in the way your working tree is modified. Can you give more details?
Reproducible using v1.8.1-rc3 and master. Bisects to 4337b585 (do not write null sha1s to on-disk index, 2012-07-28). For comparison, older gits produced $ git am --abort Unstaged changes after reset: M sound/usb/midi.c
What does your index look like afterwards? Does it have a null sha1 in it (check "ls-files -s")? -Peff