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

Re: [PATCH] Remove unused assignments

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 14, 2009, 20:18 UTC
Message-ID
<7v7i2rc0zp.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<49BA56D5.5050807@googlemail.com>
Benjamin Kramer <benny.kra@googlemail.com> writes:
Show 13 quoted lines
> These variables were always overwritten or the assigned
> value was unused:
>
> builtin-diff-tree.c::cmd_diff_tree(): nr_sha1
> builtin-for-each-ref.c::opt_parse_sort(): sort_tail
> builtin-mailinfo.c::decode_header_bq(): in
> builtin-shortlog.c::insert_one_record(): len
> connect.c::git_connect(): path
> imap-send.c::v_issue_imap_cmd(): n
> pretty.c::pp_user_info(): filler
> remote::parse_refspec_internal(): llen
>
> Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com>

Thanks. I eyeballed all of them and they look safe, but this patch made me wonder...

Did you use some dataflow analysis tool to spot these?

It will never scale if a human has to sanity check output from a mechanical process like this patch, especially when the human is already a chokepoint of the whole process (i.e. the maintainer).

We'd need some process improvements in the longer term to handle patches like this, but I do not think of a good one offhand.

I do not think we want to trust tool output blindly; it will not solve the issue to give me the recipe for the mechanical process you used, to have me run it and to make me trust the result without checking. We would want to keep some human whose judgement we can trust in the loop to always check the changes mechanical analysis tools may produce.

I think the only viable long term solution would be to keep doing the manual verification I did like this round until somebody like you accumulate enough "trust points" in the community for consistently sending good patches like this one to allow me to apply patches from these people blindly, trusting the sender's judgement.

But please disregard all of the above if you spotted these by manual inspection.

I think the patch to pp_user_info() can go one step further. The filler is used at only one place after this patch, as a strong given to one of the placeholders in strbuf_addf(). We can simply feed a constant to the function instead, like this:

diff --git a/pretty.c b/pretty.c
index 3a24cd5..efa7024 100644
--- a/pretty.c
+++ b/pretty.c
@@ -135,7 +135,6 @@ void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
 	int namelen;
 	unsigned long time;
 	int tz;
-	const char *filler = "    ";
 
 	if (fmt == CMIT_FMT_ONELINE)
 		return;
@@ -161,7 +160,7 @@ void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
 	} else {
 		strbuf_addf(sb, "%s: %.*s%.*s\n", what,
 			      (fmt == CMIT_FMT_FULLER) ? 4 : 0,
-			      filler, namelen, line);
+			      "    ", namelen, line);
 	}
 	switch (fmt) {
 	case CMIT_FMT_MEDIUM:
Previous: Benjamin KramerNext: Benjamin Kramer
Message 2 of 3 in “Remove unused assignments”
  1. Remove unused assignmentsBenjamin Kramer, Mar 13, 2009
  2. Junio C HamanoMar 14, 2009
  3. Benjamin KramerMar 14, 2009

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.