repo: 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.

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

gitgitgadget

From: Mansi <[email protected]>

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"

---
 t/t7605-merge-resolve.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

index 5d56c38546..44de97a480 100755
@@ -34,9 +34,9 @@ merge_c1_to_c2_cmds='
 	test "$(git rev-parse c1)" = "$(git rev-parse HEAD^1)" &&
 	test "$(git rev-parse c2)" = "$(git rev-parse HEAD^2)" &&
 	git diff --exit-code &&
-	test -f c0.c &&
-	test -f c1.c &&
-	test -f c2.c &&
+	test_path_is_file c0.c &&
+	test_path_is_file c1.c &&
+	test_path_is_file c2.c &&
 	test 3 = $(git ls-tree -r HEAD | wc -l) &&
 	test 3 = $(git ls-files | wc -l)
 '

gitgitgadget

From: Mansi Singh <[email protected]>

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.

---
 builtin/repo.c | 1 -
 1 file changed, 1 deletion(-)

index 0ea045abc1..5540bd25d2 100644
@@ -412,7 +412,6 @@ static void stats_table_print_structure(const struct stats_table *table)
 		const char *unit = "";
 
 		if (entry) {
-			struct stats_table_entry *entry = item->util;
 			value = entry->value;
 			if (entry->unit)
 				unit = entry->unit;

gitgitgadget

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/[email protected]/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

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/[email protected]/
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.