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

Re: [PATCHv10 02/10] receive-pack.c: die instead of error in assure_connectivity_checked

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Jan 5, 2015, 21:25 UTC
Message-ID
<20150105212523.GN29365@google.com>
In-Reply-To
<CAGZ79kZUiwEbcSPk3Td60umixvh_Q7jXTGoLemKLYsvX1ty39w@mail.gmail.com>
Stefan Beller wrote:
Show 7 quoted lines
> Maybe we should do both?
>
>     die ("BUG: Some refs have not been checked for connectivity."
>           "Please contact the git developers (git@vger.kernel.org) and"
>           "report the problem. As a workaround run 'git fsck'. If there"
>           "are errors, try to remove the reported refs above. (This "
>           "may lead to data loss, backup first.)"

I personally find this kind of message grating when I run into it. The message is trying to tell me what to do, but it is not in a position to know what the best thing to do is.

It could be that I am using an ancient version of git with known bugs. In that case I should upgrade.

It could be that I am using faulty hardware that flips random bits and confuses software.

It could be that I have a patched version of git, in which case I should contact the author of my patch instead of git@vger.kernel.org.

It could be that this is a recent, terrible regression and git@vger.kernel.org is already bombarded with reports about it.

If the message says
	fatal: BUG: connectivity check skipped???

then it has exactly the right amount of information to tell me what to do. Now I have

 - a short string to grep for in the source code (or on the web) to
   find out what happened
 - a clear indication that This Can't Happen, so I know to try to
   reproduce it and contact the author of my patched git or upstream
   or whoever, depending on the context
 - no irrelevant guesses to confuse me

The workaround of running 'git fsck' could be actively harmful, depending on what the bug is. All that we know is that a bug has occured and we shouldn't proceed further.

> Just thinking out loud:
[...]
>                  Would it make sense to have an extra die_bug function,

Yes, I think something like the kernel's BUG_ON and WARN_ON would be very nice (though orthogonal to this change).

Thanks, Jonathan

Previous: Stefan BellerNext: Stefan Beller
Message 10 of 24 in “atomic pushes”
  1. 0/9 atomic pushesStefan Beller, Dec 30, 2014
  2. 1/9 receive-pack.c: shorten the execute_commands loop over all commandsStefan Beller, Dec 30, 2014
  3. Jonathan NiederJan 3, 2015
  4. Duy NguyenJan 3, 2015
  5. Stefan BellerJan 5, 2015
  6. 01/10 receive-pack.c: shorten the execute_commands loop over all commandsStefan Beller, Jan 5, 2015
  7. 02/10 receive-pack.c: die instead of error in assure_connectivity_checkedStefan Beller, Jan 5, 2015
  8. Jonathan NiederJan 5, 2015
  9. Stefan BellerJan 5, 2015
  10. Jonathan NiederJan 5, 2015
  11. 02/11 receive-pack.c: die instead of error in case of possible future bugStefan Beller, Jan 6, 2015
  12. Jonathan NiederJan 6, 2015
  13. Jonathan NiederJan 5, 2015
  14. Stefan BellerJan 5, 2015
  15. Jonathan NiederJan 5, 2015
  16. 01/11 receive-pack.c: shorten the execute_commands loop over all commandsStefan Beller, Jan 6, 2015
  17. 2/9 receive-pack.c: move iterating over all commands outside execute_commandsStefan Beller, Dec 30, 2014
  18. 3/9 receive-pack.c: move transaction handling in a central placeStefan Beller, Dec 30, 2014
  19. 4/9 receive-pack.c: add execute_commands_atomic functionStefan Beller, Dec 30, 2014
  20. 5/9 receive-pack.c: negotiate atomic push supportStefan Beller, Dec 30, 2014
  21. 6/9 send-pack: rename ref_update_to_be_sent to check_to_send_updateStefan Beller, Dec 30, 2014
  22. 7/9 send-pack.c: add --atomic command line argumentStefan Beller, Dec 30, 2014
  23. 8/9 push.c: add an --atomic argumentStefan Beller, Dec 30, 2014
  24. 9/9 t5543-atomic-push.sh: add basic tests for atomic pushesStefan Beller, Dec 30, 2014

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.