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
Stefan Beller <sbeller@google.com>
Date
Jan 5, 2015, 21:15 UTC
Message-ID
<CAGZ79kZUiwEbcSPk3Td60umixvh_Q7jXTGoLemKLYsvX1ty39w@mail.gmail.com>
In-Reply-To
<20150105201728.GK29365@google.com>
On Mon, Jan 5, 2015 at 12:17 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 17 quoted lines
> Stefan Beller wrote:
>
>> --- a/builtin/receive-pack.c
>> +++ b/builtin/receive-pack.c
>> @@ -1055,15 +1055,15 @@ static void assure_connectivity_checked(struct command *commands,
>>
>>       for (cmd = commands; cmd; cmd = cmd->next) {
>>               if (should_process_cmd(cmd) && si->shallow_ref[cmd->index]) {
>> -                     error("BUG: connectivity check has not been run on ref %s",
>> -                           cmd->ref_name);
>> +                     die("BUG: connectivity check has not been run on ref %s",
>> +                         cmd->ref_name);
>
> This could stay as error() so that the caller gets to see the list of
> refs that didn't experience a connectivity check.  Or if that list
> isn't important, this error/die call could be dropped and the
> 'checked_connectivity = 0' setting would be enough.

Right. I was once again writing patches without brain activity. So we'd keep this as an error.

Show 18 quoted lines
>
>>                       checked_connectivity = 0;
>>               }
>>       }
>>       if (!checked_connectivity)
>> -             error("BUG: run 'git fsck' for safety.\n"
>> -                   "If there are errors, try to remove "
>> -                   "the reported refs above");
>> +             die("BUG: run 'git fsck' for safety.\n"
>> +                 "If there are errors, try to remove "
>> +                 "the reported refs above");
>
> I find this error message misleading and confusing.  It makes it seem
> like this is an expected error that we are trying to help the user
> recover from.  Instead, something impossible has happened.  "Try to
> remove the reported refs" is actively harmful advice --- that would be
> a way for the user to work around a serious bug instead of figuring
> out what went wrong and getting git fixed.
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.)"

Just thinking out loud: We are using die(...) for two kinds of problems. Either because of some bad condition given to us by the user (wrong/meaningless arguments) which we then to refuse to accept.

The other case is usually die("BUG: Git is broken in some way") as we're discussing here. Would it make sense to have an extra die_bug function, which amends the reported error string by something like

    "Please contact the git developers (git@vger.kernel.org) and
report the problem."
as above?

Thanks, Stefan

>
> Jonathan
Previous: Jonathan NiederNext: Jonathan Nieder
Message 9 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.