patch, 2 partsrepo: remove redundant variable shadow in stats_table_print_structure

The variable i is declared in the outer scope of stats_table_print_structure() and then re-declared inside the loop, shadowing the outer one unnecessarily. Remove the redundant inner declaration to clean up the scope.

Signed-off-by: Mansi Singh mansimaanu8627@gmail.com

Mansi (1):
  t7605: use test_path_is_file instead of test -f

Mansi Singh (1):
  repo: remove redundant variable shadow in stats_table_print_structure

 builtin/repo.c           | 1 -
 t/t7605-merge-resolve.sh | 6 +++---
 2 files changed, 3 insertions(+), 4 deletions(-)

base-commit: 7c02d39fc2ed2702223c7674f73150d9a7e61ba4
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2062%2FMansiSingh17%2Frepo-fix-variable-shadow-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2062/MansiSingh17/repo-fix-variable-shadow-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2062

From: Mansi <mansimaanu8627@gmail.com>

Replace old-style 'test -f' path checks with the modern test_path_is_file helper in the merge_c1_to_c2_cmds block.

The helper provides clearer failure messages and is the established convention in Git's test suite.

These instances were found using:
  grep -rn "test -[efd]" t/ --include="*.sh"

Signed-off-by: Mansi <mansimaanu8627@gmail.com>
---
 t/t7605-merge-resolve.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

From: Mansi Singh <mansimaanu8627@gmail.com>

In stats_table_print_structure(), the variable 'entry' is declared at the top of the loop body and assigned from item->util. Inside the 'if (entry)' block, the same variable is redeclared and assigned identically, shadowing the outer declaration unnecessarily.

Remove the inner redeclaration since the outer 'entry' is already available and non-NULL at that point.

Signed-off-by: Mansi Singh <mansimaanu8627@gmail.com>
---
 builtin/repo.c | 1 -
 1 file changed, 1 deletion(-)

Hi Mansi,

This is a good catch but I have to say this patch is already sent by me And is also merged into the master branch [1].

You can search in the mailing list or sometimes check the "What's cooking in git.git" (recent one [2]) before making the changes. You don't need anyone's permission to work on a patch but it is also important to not step on someone's toes ;)

1 - https://github.com/git/git/commit/676c145afdd88024057296f11fdf2c224001549e 2 - https://lore.kernel.org/git/xmqqh5qozdkq.fsf@gitster.g/T/#u

coming to the double naming problem That is because one of your patch is using `format-patch` and `send-email` method of sending patches and the other one is using `gitgitgadget`.

My suggestion would be to stick with one and move forward with that for the entirety.

Regards,
- Jayatheerth

"Mansi Singh via GitGitGadget" <gitgitgadget@gmail.com> writes:

The above sounds more like a description for a single patch, not a cover letter.

Because we strongly encourage one patch doing only one thing and doing it well, a commit log message for one of the patches in a two-patch series rarely makes a good description for the whole series.

But reading it again, which variable 'i' is it talking about? [2/2] does address 'entry' that is declared in an inner scope, masking the variable with the same name declared in an outer scope.

Stepping back a bit, I do not quite see the need for these two patcches to form a single topic. They look pretty much totally independent topics. Perhaps you're better off treating them as two independent topics, each with a single patch.

Are these two patches from two different people?

Last time in https://lore.kernel.org/git/xmqqv7fjw6yx.fsf@gitster.g/ we had three names, and we now have only two, so that can be called an improvement, but let's whittle them down to just one ;-).

Thanks.