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

Re: [PATCHv9 1/9] receive-pack.c: shorten the execute_commands loop over all commands

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Jan 3, 2015, 02:20 UTC
Message-ID
<20150103022004.GI29365@google.com>
In-Reply-To
<1419982898-23108-2-git-send-email-sbeller@google.com>

(+cc: Duy, who understands shallow push well) Hi,

Stefan Beller wrote:
> This commit shortens execute_commands loop over all commands by moving

The commit message can be simplified by leaving out "This commit" and stating what the commit does in the imperative, focusing on what problem the commit solves.

For example:
	Make the main "execute_commands" loop in receive-pack easier to read
	by splitting out some steps into helper functions.  The new helper
	'should_process_cmd' checks if a ref update is unnecessary, whether
	due to an error having occured or for another reason.  The helper
	'check_shallow_bugs' warns if we have forgotten to run a connectivity
	check on a ref which is shallow for the client.
	This will help us to duplicate less code in a later patch when we make
	a second copy of the "execute_commands" loop.
	No functional change intended.

By the way, is there some clearer name for check_shallow_bugs? That name makes it sound like there are some bugs we are checking up on, whereas a name that makes it obvious what the function will do and saves me from having to read the function body would be ideal.

[...]
> +++ b/builtin/receive-pack.c
[...]
> @@ -1077,27 +1099,15 @@ static void execute_commands(struct command *commands,
[...]
>  	for (cmd = commands; cmd; cmd = cmd->next) {
[...]
Show 14 quoted lines
> -		if (shallow_update && !cmd->error_string &&
> -		    si->shallow_ref[cmd->index]) {
> -			error("BUG: connectivity check has not been run on ref %s",
> -			      cmd->ref_name);
> -			checked_connectivity = 0;
> -		}
>  	}
>
> -	if (shallow_update && !checked_connectivity)
> -		error("BUG: run 'git fsck' for safety.\n"
> -		      "If there are errors, try to remove "
> -		      "the reported refs above");
> +	if (shallow_update)
> +		check_shallow_bugs(commands, si);

In the same spirit of saving the reader from having to look at the body of check_shallow_bugs, would it make sense for the part that reacts to an error to be kept in the caller? E.g.:

	if (shallow_update && warn_if_skipped_connectivity_check(commands, si))
		error("BUG: run 'git fsck for safety.\n"
		      "If there are errors, try removing the refs reported above");

Is this error possible, by the way? update() does not return success unless it has reached the bottom block in the function. In the !is_null_sha1(new_sha1) case that means it calls update_shallow_ref(), which performs the connectivity check. In the is_null_sha1(new_sha1) case, update_shallow_info() does not set cmd->index and si->shallow_ref[cmd->index] cannot be set.

Perhaps this error message could be written in a way that makes it clearer that we really expect it not to happen, like

		die("BUG: connectivity check skipped in shallow push???");

(die() instead of error() to prevent refs from updating and pointing to a disconnected history).

Thoughts? Jonathan

Previous: Stefan BellerNext: Duy Nguyen
Message 3 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.