threads / patch / 51937

v3commit-graph: remove a duplicate assignment

Subject: [PATCH v3] commit-graph: remove a duplicate assignment

## tl;dr

3 messages between Sep 29, 2019 and Sep 30, 2019. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Alex Henrie· Sep 29, 2019, 00:55 UTC · lore

The variable g was being set to the same value both at the beginning of the function and before the loop. The assignment before the loop was kept because it helps clarify what the loop does, and the redundant assignment at the beginning of the function was removed.

Reviewed-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
---
 commit-graph.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Show changes to commit-graph.c +1 −1

diff --git a/commit-graph.c b/commit-graph.c
index 9b02d2c426..d0e1f9e1f2 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -1522,7 +1522,7 @@ static int write_commit_graph_file(struct write_commit_graph_context *ctx)
 
 static void split_graph_merge_strategy(struct write_commit_graph_context *ctx)
 {
-	struct commit_graph *g = ctx->r->objects->commit_graph;
+	struct commit_graph *g;
 	uint32_t num_commits = ctx->commits.nr;
 	uint32_t i;

-- 
2.23.0

Junio C Hamano· Sep 30, 2019, 01:22 UTC · re: Alex Henrie · lore

Re: [PATCH v3] commit-graph: remove a duplicate assignment

Alex Henrie <alexhenrie24@gmail.com> writes:

> The variable g was being set to the same value both at the beginning of
> the function and before the loop. The assignment before the loop was
> kept because it helps clarify what the loop does, and the redundant
> assignment at the beginning of the function was removed.

Writing these mostly in the past tense is misleading to those who are used to read "git log" from this project. Give orders to the codebase to "become like so" instead. Perhaps like

	Leave the variable 'g' uninitialized before it is set just
	before its first use in front of a loop, which is a lot more
	appropriate place to indicate what it is used for.

Show 5 quoted lines

>  static void split_graph_merge_strategy(struct write_commit_graph_context *ctx)
>  {
> -	struct commit_graph *g = ctx->r->objects->commit_graph;
> +	struct commit_graph *g;
>  	uint32_t num_commits = ctx->commits.nr;

Stepping back a bit, doesn't the same justification you gave to this change apply to 'num_commits'? If you make it uninitialized before its first use and assign ctx->commits.nr to it near where 'g' is given its first value, wouldn't it make it even clearer that these two variables are almost always used together and how they are used in the loop?

Alex Henrie· Sep 30, 2019, 07:34 UTC · re: Junio C Hamano · lore

Re: [PATCH v3] commit-graph: remove a duplicate assignment

On Sun, Sep 29, 2019 at 7:22 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

>
> Alex Henrie <alexhenrie24@gmail.com> writes:
>
> > The variable g was being set to the same value both at the beginning of
> > the function and before the loop. The assignment before the loop was
> > kept because it helps clarify what the loop does, and the redundant
> > assignment at the beginning of the function was removed.
>
> Writing these mostly in the past tense is misleading to those who
> are used to read "git log" from this project.  Give orders to the
> codebase to "become like so" instead.  Perhaps like
>
>         Leave the variable 'g' uninitialized before it is set just
>         before its first use in front of a loop, which is a lot more
>         appropriate place to indicate what it is used for.

Okay, thanks for the guidance. I'll use your text on the next version of the patch.

Show 12 quoted lines

> >  static void split_graph_merge_strategy(struct write_commit_graph_context *ctx)
> >  {
> > -     struct commit_graph *g = ctx->r->objects->commit_graph;
> > +     struct commit_graph *g;
> >       uint32_t num_commits = ctx->commits.nr;
>
> Stepping back a bit, doesn't the same justification you gave to this
> change apply to 'num_commits'?  If you make it uninitialized before
> its first use and assign ctx->commits.nr to it near where 'g' is
> given its first value, wouldn't it make it even clearer that these
> two variables are almost always used together and how they are used
> in the loop?

Yes, that makes sense. I'll send a revised patch that includes that change as well.

-Alex