Patch recommendation for replace invoke of error() to that of error_errno()

Our team researches on consistent update of Git during evolution. And we have figured out several spots that may be missed. 

By mining historical patches, we suggest that invokes of error(..., strerror(errno)) should be replaced with that of error_errno(). One example for recommendation and corresponding patch are listed as follows. 

One example of missed spot:

1  int cmd_fetch__tool(int argc, const char **argv, const char 
  *prefix)
2  {
....
31  filename = git_path_fetch_head();
32  fp = fopen(filename, "a");
33  if (!fp)
34  return error("cannot open %s: %s", filename, strerror(errno));
....
  }

One example of historical patch: 1 if (!strcmp(*paths, "-")) 2 in = stdin; 3 else 4 in = fopen(*paths, "r"); 5 6 if (!in) 7 - return error(_("could not open '%s' for reading: %s"), 8 - *paths, strerror(errno)); 9 + return error_errno(_("could not open '%s' for reading"), 10 + *paths); 11 12 mail = mkpath("%s/%0*d", state->dir, state->prec, i + 1); 13 14 out = fopen(mail, "w"); 15 if (!out) 16 - return error(_("could not open '%s' for writing: %s"), 17 - mail, strerror(errno)); 18 + return error_errno(_("could not open '%s' for writing"), 19 + mail); 20 21 ret = fn(out, in, keep_cr); 22 23 fclose(out); 24 fclose(in); 25 More recommendations and supporting patches are saved in attachments. It is so kind of you to reply me about the correctness of our suggestions. And thank you for your reading. 

On Fri, Jan 05, 2018 at 11:24:02AM +0800, 牛旭 wrote:

Yes, historically we've done cleanups like this across time as we touch the various pieces of code. More conversions are welcome as long as they don't conflict with any topics that other people are working on (a good test is to see if your suggested changes merge cleanly with the "pu" branch).

In more recent times, we've been using the Coccinelle tool to do automated conversions across the code base. Look at the contents and history of the contrib/coccinelle directory. This might be a candidate for that cleanup.

This one is actually a bit funny. It's in contrib/examples, which is all historical code. It's not compiled or used as part of Git (and I'd suspect most of it would not compile at all these days). It's not really worth modernizing.

Eek, word documents. We're happy to take patches, but please format them as plain text in your email (e.g., by using git-send-email). More details are in Documentation/SubmittingPatches. Thanks.

-Peff

Our team studies the consistent edits of git during evolution. And we find several missed edits in the latest release of git. For example, there are two consist edits we have figured out from historical commits:
1) . Version: git 2.3.9 – git-2.3.10
       File: builtin/merge-tree.c

 	dst.size = size;
-	xdi_diff(&src, &dst, &xpp, &xecfg, &ecb);
+	if (xdi_diff(&src, &dst, &xpp, &xecfg, &ecb))
+		die("unable to generate diff");
 	free(src.ptr);
 	free(dst.ptr);
 }

2) .Version: git 2.3.9 – git-2.3.10
      File: combine-diff.c
  
-	xdi_diff_outf(&parent_file, result_file, consume_line, &state,
-		      &xpp, &xecfg);
+	if (xdi_diff_outf(&parent_file, result_file, consume_line, &state,
+			  &xpp, &xecfg))
+		die("unable to generate combined diff for %s",
+		    sha1_to_hex(parent));
 	free(parent_file.ptr);

Those two commits both add if structure and log messages for handling the return value of xdi_diff_outf(). 
And in the latest release, we find one candidate that may also need log statements inserted:
1)  File: git-2.14.2/builtin/rerere.c
    
     1	static int diff_two(const char *file1, const char *label1,
     2			const char *file2, const char *label2)
     3	{
….
    20		ret = xdi_diff(&minus, &plus, &xpp, &xecfg, &ecb);
    21	
    22		free(minus.ptr);
    23		free(plus.ptr);
    24		return ret;
    25	}
...
}

There are more examples of consistent update and corresponding suggestions in attachment. It is so nice of you to read them and share me with your opinion on the correctness of our suggestion. Thanks a lot. 

On Sun, Jan 28, 2018 at 7:46 AM, 牛旭 <niuxu16@nudt.edu.cn> wrote:

Thanks for studying the code of Git. It will help the project in bettering the code. Welcome to the Git community! Which version do you mean by "latest release" ?

Thanks a lot for this suggestion and the suggestions in the attachment.

However these are less than optimal to consume for the project. Care to make these changes as actual commits in your local repository and then send patches?

See Documentation/SubmittingPatches https://github.com/git/git/blob/master/Documentation/SubmittingPatches

Thanks, Stefan