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

Re: [PATCHv10 01/10] receive-pack.c: shorten the execute_commands loop over all commands

From
Stefan Beller <sbeller@google.com>
Date
Jan 5, 2015, 21:07 UTC
Message-ID
<CAGZ79kbRLPYRw+iifigRHqJ5Lc1brQ3qkUV=4YYPSwr72+giPg@mail.gmail.com>
In-Reply-To
<20150105202244.GL29365@google.com>
On Mon, Jan 5, 2015 at 12:22 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 15 quoted lines
> Stefan Beller wrote:
>
>> --- a/builtin/receive-pack.c
>> +++ b/builtin/receive-pack.c
> [...]
>> @@ -1077,27 +1100,15 @@ static void execute_commands(struct command *commands,
> [...]
>> +     if (shallow_update)
>> +             assure_connectivity_checked(commands, si);
>
> Looking at this code alone, it seems like assure_connectivity_checked()
> is going to ensure that connectivity was checked, so that I can assume
> connectivity going forward.  But the opposite is true --- it is a
> safety check that prints a warning and doesn't affect what I can
> assume.

I disagree on that. Combined with the next patch (s/error/die/) we can assume that the the connectivity is there as if it is not, git is dead.

This is why I choose the word assure. Maybe check_assumption would be better?
Show 6 quoted lines
>
> The factored-out function fails in what it is meant to do, which is to
> save the reader of execute_commands from having to look at the
> implementation of the parts they are not interested in.
>
> Would something like warn_if_skipped_connectivity_check() make sense?

The next patch would then change this to die_if_... ? I'd be ok with that, but in your original email you would still have the last die(...) in the execute_command function which I dislike. So what about:

if (shallow_update)
       (warn|die)_on_skipped_connectivity_check()
?
>
> Jonathan
Previous: Jonathan NiederNext: Jonathan Nieder
Message 14 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.