git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/3] do not write null sha1s to on-disk index

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Dec 29, 2012, 10:03 UTC
Message-ID
<20121229100130.GA31497@elie.Belkin>
In-Reply-To
<20120728150524.GB25269@sigill.intra.peff.net>
Hi Peff,
Jeff King wrote:
Show 10 quoted lines
> --- 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:

  $ 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
  $

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

which is also not great but at least didn't involve any obviously invalid behavior. Known problem?

Thanks, Jonathan

Previous: Jeff KingNext: Jeff King
Message 4 of 22 in “null sha1 in trees”
  1. 0/3 null sha1 in treesJeff King, Jul 28, 2012
  2. 1/3 diff: do not use null sha1 as a sentinel valueJeff King, Jul 28, 2012
  3. 2/3 do not write null sha1s to on-disk indexJeff King, Jul 28, 2012
  4. Jonathan NiederDec 29, 2012
  5. Jeff KingDec 29, 2012
  6. Jonathan NiederDec 29, 2012
  7. Jeff KingDec 29, 2012
  8. Jonathan NiederDec 29, 2012
  9. Jeff KingDec 29, 2012
  10. [BUG] two-way read-tree can write null sha1s into indexJeff King, Dec 29, 2012
  11. Junio C HamanoJan 1, 2013
  12. Jeff KingJan 3, 2013
  13. Junio C HamanoJan 3, 2013
  14. Jeff KingJan 3, 2013
  15. Junio C HamanoJan 3, 2013
  16. Jeff KingJan 3, 2013
  17. Junio C HamanoJan 3, 2013
  18. Jeff KingJan 7, 2013
  19. Jonathan NiederDec 29, 2012
  20. 3/3 fsck: detect null sha1 in tree entriesJeff King, Jul 28, 2012
  21. Junio C HamanoJul 29, 2012
  22. Jeff KingJul 30, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.