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

Re: [PATCH v3 1/2] for-each-repo: optionally keep going on an error

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 24, 2024, 17:02 UTC
Message-ID
<xmqqfrvazobm.fsf@gitster.g>
In-Reply-To
<39ee6386aab25f28d197a27010b2f80ccd45aab2.1713975300.git.gitgitgadget@gmail.com>

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 17 quoted lines
> @@ -55,8 +58,14 @@ int cmd_for_each_repo(int argc, const char **argv, const char *prefix)
>  	else if (err)
>  		return 0;
>  
> -	for (i = 0; !result && i < values->nr; i++)
> -		result = run_command_on_repo(values->items[i].string, argc, argv);
> +	for (i = 0; i < values->nr; i++) {
> +		int ret = run_command_on_repo(values->items[i].string, argc, argv);
> +		if (ret) {
> +			if (!keep_going)
> +					return ret;
> +			result = 1;
> +		}
> +	}
>  
>  	return result;
>  }

Hmph, as I wish that more experienced folks to give a good structure to the codebase from get-go so that future developers who may be less experienced would avoid mistakes, with my maintainer's hat on, I would have expected something more like:

	for (i = 0; i < values->nr; i++) {
		int ret = run_command_on_repo(...);
		if (!ret)
			continue;
		if (keep_going) {
                	result = 1;			
		} else {
                	result = ret;
                        break;
		}
	}

That way, clean-up actions, when they need to be added, can go before the single "return result" without structural changes, future-proofing the shape of the control flow.

The loop is simple enough that it is acceptable to leave as the responsibility of future developers who wants to do something that require resource allocation and release before returning, of course ;-).

Previous: Johannes Schindelin via GitGitGadgetNext: Johannes Schindelin via GitGitGadget
Message 17 of 19 in “Use a "best effort" strategy in scheduled maintenance”
  1. 0/2 Use a "best effort" strategy in scheduled maintenanceJohannes Schindelin via GitGitGadget, Apr 17, 2024
  2. 1/2 for-each-repo: optionally keep going on an errorJohannes Schindelin via GitGitGadget, Apr 17, 2024
  3. Eric SunshineApr 17, 2024
  4. Junio C HamanoApr 17, 2024
  5. 2/2 maintenance: running maintenance should not stop on errorsJohannes Schindelin via GitGitGadget, Apr 17, 2024
  6. Junio C HamanoApr 17, 2024
  7. Junio C HamanoApr 17, 2024
  8. 0/2 Use a "best effort" strategy in scheduled maintenanceJohannes Schindelin via GitGitGadget, Apr 18, 2024
  9. 1/2 for-each-repo: optionally keep going on an errorJohannes Schindelin via GitGitGadget, Apr 18, 2024
  10. Patrick SteinhardtApr 19, 2024
  11. Junio C HamanoApr 19, 2024
  12. Jeff KingApr 19, 2024
  13. Junio C HamanoApr 22, 2024
  14. 2/2 maintenance: running maintenance should not stop on errorsJohannes Schindelin via GitGitGadget, Apr 18, 2024
  15. 0/2 Use a "best effort" strategy in scheduled maintenanceJohannes Schindelin via GitGitGadget, Apr 24, 2024
  16. 1/2 for-each-repo: optionally keep going on an errorJohannes Schindelin via GitGitGadget, Apr 24, 2024
  17. Junio C HamanoApr 24, 2024
  18. 2/2 maintenance: running maintenance should not stop on errorsJohannes Schindelin via GitGitGadget, Apr 24, 2024
  19. Patrick SteinhardtApr 25, 2024

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.