Re: [PATCH v4 02/11] commit-graph: return with errors during write

[Junio C Hamano <gitster@pobox.com>]

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Derrick Stolee <dstolee@microsoft.com>
>
> The write_commit_graph() method uses die() to report failure and
> exit when confronted with an unexpected condition. This use of
> die() in a library function is incorrect and is now replaced by
> error() statements and an int return type.

OK.

> diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
> index 537fdfd0f0..2e86251f02 100644
> --- a/builtin/commit-graph.c
> +++ b/builtin/commit-graph.c
> @@ -141,6 +141,7 @@ static int graph_write(int argc, const char **argv)
>  	struct string_list *pack_indexes = NULL;
>  	struct string_list *commit_hex = NULL;
>  	struct string_list lines;
> +	int result;
>  
>  	static struct option builtin_commit_graph_write_options[] = {
>  		OPT_STRING(0, "object-dir", &opts.obj_dir,
> @@ -168,10 +169,8 @@ static int graph_write(int argc, const char **argv)
>  
>  	read_replace_refs = 0;
>  
> -	if (opts.reachable) {
> -		write_commit_graph_reachable(opts.obj_dir, opts.append, 1);
> -		return 0;
> -	}
> +	if (opts.reachable)
> +		return write_commit_graph_reachable(opts.obj_dir, opts.append, 1);
>  
>  	string_list_init(&lines, 0);
>  	if (opts.stdin_packs || opts.stdin_commits) {
> @@ -188,14 +187,14 @@ static int graph_write(int argc, const char **argv)
>  		UNLEAK(buf);
>  	}
>  
> -	write_commit_graph(opts.obj_dir,
> -			   pack_indexes,
> -			   commit_hex,
> -			   opts.append,
> -			   1);
> +	result = write_commit_graph(opts.obj_dir,
> +				    pack_indexes,
> +				    commit_hex,
> +				    opts.append,
> +				    1);
>  
>  	UNLEAK(lines);
> -	return 0;
> +	return result;
>  }

What were the error values this function used to return?  I am
wondering if the callers of this function are prepraed to see the
returned values from write_commit_graph() this function stores in
'result' (which presumably are small negative value like our usual
internal API convention)?


> diff --git a/builtin/commit.c b/builtin/commit.c
> index 2986553d5f..b9ea7222fa 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1669,8 +1669,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>  		      "new_index file. Check that disk is not full and quota is\n"
>  		      "not exceeded, and then \"git reset HEAD\" to recover."));
>  
> -	if (git_env_bool(GIT_TEST_COMMIT_GRAPH, 0))
> -		write_commit_graph_reachable(get_object_directory(), 0, 0);
> +	if (git_env_bool(GIT_TEST_COMMIT_GRAPH, 0) &&
> +	    write_commit_graph_reachable(get_object_directory(), 0, 0))
> +		return 1;

This is good.  An error signalled as a small negative integer would
not seep thru to the exit status but is explicitly turned into 1
with this change.

> +	if (gc_write_commit_graph &&
> +	    write_commit_graph_reachable(get_object_directory(), 0,
> +					 !quiet && !daemonized))
> +		return 1;

Ditto.

> +int write_commit_graph_reachable(const char *obj_dir, int append,
> +				 int report_progress)
>  {
>  	struct string_list list = STRING_LIST_INIT_DUP;
> +	int result;
>  
>  	for_each_ref(add_ref_to_list, &list);
> -	write_commit_graph(obj_dir, NULL, &list, append, report_progress);
> +	result = write_commit_graph(obj_dir, NULL, &list,
> +				    append, report_progress);
>  
>  	string_list_clear(&list, 0);
> +	return result;
>  }

OK.  The callers of write_commit_graph_reachable() can be careful
about its return values to the same degree as the callers of
write_commit_graph().

These functions perhaps deserves
/*
 * returns X when ....
 */
in front (or in *.h)?

> +int write_commit_graph(const char *obj_dir,
> +		       struct string_list *pack_indexes,
> +		       struct string_list *commit_hex,
> +		       int append, int report_progress)
>  {
>  	struct packed_oid_list oids;
>  	struct packed_commit_list commits;
>  	struct hashfile *f;
>  	uint32_t i, count_distinct = 0;
> -	char *graph_name;
> +	char *graph_name = NULL;
>  	struct lock_file lk = LOCK_INIT;
>  	uint32_t chunk_ids[5];
>  	uint64_t chunk_offsets[5];
> @@ -883,15 +886,17 @@ void write_commit_graph(const char *obj_dir,
>  	uint64_t progress_cnt = 0;
>  	struct strbuf progress_title = STRBUF_INIT;
>  	unsigned long approx_nr_objects;
> +	int res = 0;
>  
>  	if (!commit_graph_compatible(the_repository))
> -		return;
> +		return 0;

OK.  I tend to find "return 0" easier to read/follow than "return
res" here.

>  	oids.nr = 0;
>  	approx_nr_objects = approximate_object_count();
>  	oids.alloc = approx_nr_objects / 32;
>  	oids.progress = NULL;
>  	oids.progress_done = 0;
> +	commits.list = NULL;
>  
>  	if (append) {
>  		prepare_commit_graph_one(the_repository, obj_dir);
> @@ -932,10 +937,16 @@ void write_commit_graph(const char *obj_dir,
>  			strbuf_setlen(&packname, dirlen);
>  			strbuf_addstr(&packname, pack_indexes->items[i].string);
>  			p = add_packed_git(packname.buf, packname.len, 1);
> -			if (!p)
> -				die(_("error adding pack %s"), packname.buf);
> -			if (open_pack_index(p))
> -				die(_("error opening index for %s"), packname.buf);
> +			if (!p) {
> +				error(_("error adding pack %s"), packname.buf);
> +				res = 1;
> +				goto cleanup;
> +			}
> +			if (open_pack_index(p)) {
> +				error(_("error opening index for %s"), packname.buf);
> +				res = 1;
> +				goto cleanup;
> +			}

Hmph, is this signal an error by returning a positive "1"?  That's a
bit unusual.

> @@ -1006,8 +1017,11 @@ void write_commit_graph(const char *obj_dir,
>  	}
>  	stop_progress(&progress);
>  
> -	if (count_distinct >= GRAPH_EDGE_LAST_MASK)
> -		die(_("the commit graph format cannot write %d commits"), count_distinct);
> +	if (count_distinct >= GRAPH_EDGE_LAST_MASK) {
> +		error(_("the commit graph format cannot write %d commits"), count_distinct);
> +		res = 1;
> +		goto cleanup;
> +	}
>  
>  	commits.nr = 0;
>  	commits.alloc = count_distinct;
> @@ -1039,16 +1053,21 @@ void write_commit_graph(const char *obj_dir,
>  	num_chunks = num_extra_edges ? 4 : 3;
>  	stop_progress(&progress);
>  
> -	if (commits.nr >= GRAPH_EDGE_LAST_MASK)
> -		die(_("too many commits to write graph"));
> +	if (commits.nr >= GRAPH_EDGE_LAST_MASK) {
> +		error(_("too many commits to write graph"));
> +		res = 1;
> +		goto cleanup;
> +	}
>  
>  	compute_generation_numbers(&commits, report_progress);
>  
>  	graph_name = get_commit_graph_filename(obj_dir);
>  	if (safe_create_leading_directories(graph_name)) {
>  		UNLEAK(graph_name);
> -		die_errno(_("unable to create leading directories of %s"),
> -			  graph_name);
> +		error(_("unable to create leading directories of %s"),
> +			graph_name);
> +		res = errno;
> +		goto cleanup;
>  	}

Hmph.  Do we know errno==0 means no error everywhere?  Do we know
errno==1 is not used by anybody as a meaningful value?

What I am getting at is if a hardcoded "1" we saw above as "error
exists but we are not telling the caller what kind of system-level
error led to it by returning errno" (and a hardcoded "0" as "there
is no error") are consistent with this use of "res" where "the
callers are allowed to learn what system-level error led to this
error return from this function by sending the return value of this
function to strerror() or comparing with EWHATEVER".  I do not think
this is a good design.