[GSoC][Patch 0/2] t4131: update test script

[GSoC][Patch 0/2] t4131: update test script

[Harshit Jain]

Greetings!

Here is my very first contribution to the open-source community. I have always been a great admirer of the open-source developments and am really excited to begin my journey in the open source development.

In this patch, I have:
        - modernized the script code to adhere to the CodingGuidelines
        - replaced 'test -f' with the helper function 'test_path_is_file' as it make the code more readable and also gives better error messages

Just to add, I have done this as a microproject for my GSoC application, and am hoping to contribute more to the git during the coming summers.

Thanks,
Harshit Jain

[GSoC][PATCH 1/2] t4131: modernize style

[Harshit Jain]

The tests in 't4131-apply-fake-ancestor.sh' were written a long time ago, and have a few style violations. Update it to adhere to the CodingGuidelines.

Signed-off-by: Harshit Jain <harshitjain1371999@gmail.com>
---
 t/t4131-apply-fake-ancestor.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/t4131-apply-fake-ancestor.sh b/t/t4131-apply-fake-ancestor.sh
index b1361ce546..828d1a355b 100755
--- a/t/t4131-apply-fake-ancestor.sh
+++ b/t/t4131-apply-fake-ancestor.sh
@@ -17,8 +17,8 @@ test_expect_success 'setup' '
 
 test_expect_success 'apply --build-fake-ancestor' '
 	git checkout 2 &&
-	echo "A" > 1.t &&
-	git diff > 1.patch &&
+	echo "A" >1.t &&
+	git diff >1.patch &&
 	git reset --hard &&
 	git checkout 1 &&
 	git apply --build-fake-ancestor 1.ancestor 1.patch
@@ -26,8 +26,8 @@ test_expect_success 'apply --build-fake-ancestor' '
 
 test_expect_success 'apply --build-fake-ancestor in a subdirectory' '
 	git checkout 3 &&
-	echo "C" > sub/3.t &&
-	git diff > 3.patch &&
+	echo "C" >sub/3.t &&
+	git diff >3.patch &&
 	git reset --hard &&
 	git checkout 4 &&
 	(
-- 
2.26.0.rc2

Re: [GSoC][PATCH 1/2] t4131: modernize style

[Shourya Shukla]

Hello Harshit,

> The tests in 't4131-apply-fake-ancestor.sh' were written a long time ago, and have a few style violations. Update it to adhere to the CodingGuidelines.

Maybe add a commit title and then have a body? To do so, do a 'git commit' instead of 'git commit -m "message"'. This will open a text editor
in which you can edit your commit message. You may refer to this answer I gave on StackOverflow on commit messages:

https://stackoverflow.com/a/60755299/10751129

Also, commit messages are generally around 72 characters per line. What are the
style violations you are talking about BTW?

The commit title can be of the form:

t4131: modernise style

<<commit description>>


Regards,
Shourya Shukla

Re: [GSoC][PATCH 1/2] t4131: modernize style

[Harshit Jain]

Hi Shourya,

> > The tests in 't4131-apply-fake-ancestor.sh' were written a long time ago, and have a few style violations. Update it to adhere to the CodingGuidelines.
>
> Maybe add a commit title and then have a body? To do so, do a 'git commit' instead of 'git commit -m "message"'. This will open a text editor
> in which you can edit your commit message. You may refer to this answer I gave on StackOverflow on commit messages:
>
> https://stackoverflow.com/a/60755299/10751129

I used 'git commit' only and not 'git commit -m "message". But
apparently, the git format-patch tool takes the first line of commit
message i.e. the
commit title as the file name and the lines after that as the text for
the body. And hence, the patch emails, just start with the commit
description
and not the commit title.

So, should I explicitly add the commit title in the patch files
generated or else how to handle this?

> Also, commit messages are generally around 72 characters per line. What are the
> style violations you are talking about BTW?

The git coding guidelines says that we shouldn't have a space after
the redirection operators, hence I corrected this in the test file.

Regards,
Harshit Jain

Re: [GSoC][PATCH 1/2] t4131: modernize style

[Junio C Hamano]

Harshit Jain <harshitjain1371999@gmail.com> writes:

>> > The tests in 't4131-apply-fake-ancestor.sh' were written a long
>> > time ago, and have a few style violations. Update it to adhere
>> > to the CodingGuidelines.
>> ...
> I used 'git commit' only and not 'git commit -m "message". But

I'd suggest developers, especially the new ones, to stay away from
using '-m "message"' form, too.

In your editor, you would probably have written something like

	-- -- -- -- -- the contents of editor window -- -- -- -- --
	t4131: modernize style

	The tests in 't4131-apply-fake-ancestor.sh' were written ...
	...

	-- -- -- -- -- the contents of editor window -- -- -- -- --

As you observed, the first paragraph of the log message text is
taken as the title of the commit, and "git format-patch" places the
title on the "Subject:" line (if you had more than one line in the
first paragraph, since the payload on the "Subject: " line has to be
a logically single line, you'd end up getting a single long line
that has the contents on all lines in the first paragraph).

The second and subsequent paragraphs become the body of the message.

Your title looks reasonable; there is nothing that needs to be
"fixed" or "improved" there.

Your second paragraph is not so good---it should wrap the lines at a
reasonable length (say 65-70 columns).

Your last paragraph, which consists of a single "Signed-off-by:"
line in this case, is good.  It matches the identity recorded on the
"From:" line of the message.

>> Also, commit messages are generally around 72 characters per line. What are the
>> style violations you are talking about BTW?
>
> The git coding guidelines says that we shouldn't have a space after
> the redirection operators, hence I corrected this in the test file.

That is a good thing to write in the commit log message.  

"written a long time ago" does not have much value by itself (it
does serve as a backstory to explain a half of why it does not use
the more modern style, though).  "have a few style violations." is
almost meaningless (otherwise, you would not be doing a "modernize
style" patch in the first place ;-).

	t4131: modernize style.

	The tests in t4131 leaves a SP between a redirection
	operator and the file that is the redirection target,
	which does not conform to the modern coding style.

	Fix them.

	Signed-off-by: ...

perhaps.

[GSoC][PATCH 2/2] t4131: use helper function to replace test -f <path>

[Harshit Jain]

Replace 'test -f' with the helper function 'test_path_is_file' as the helper function improves the code readability and also gives better error messages.

Signed-off-by: Harshit Jain <harshitjain1371999@gmail.com>
---
 t/t4131-apply-fake-ancestor.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t4131-apply-fake-ancestor.sh b/t/t4131-apply-fake-ancestor.sh
index 828d1a355b..21ee359632 100755
--- a/t/t4131-apply-fake-ancestor.sh
+++ b/t/t4131-apply-fake-ancestor.sh
@@ -33,7 +33,7 @@ test_expect_success 'apply --build-fake-ancestor in a subdirectory' '
 	(
 		cd sub &&
 		git apply --build-fake-ancestor 3.ancestor ../3.patch &&
-		test -f 3.ancestor
+		test_path_is_file 3.ancestor
 	) &&
 	git apply --build-fake-ancestor 3.ancestor 3.patch &&
 	test_cmp sub/3.ancestor 3.ancestor
-- 
2.26.0.rc2

Re: [GSoC][PATCH 2/2] t4131: use helper function to replace test -f <path>

[Shourya Shukla]

Hello Harshit,

> Replace 'test -f' with the helper function 'test_path_is_file' as the helper function improves the code readability and also gives better error messages.

Again the same thing, you may follow what I stated before regarding commit messages.

The commit title can be of the form:

t4131: use helpers to replace test -f <path>

<<commit description>>

If you still face any problem, feel free to drop a message :)

Regards,
Shourya Shukla

Re: [GSoC][PATCH 2/2] t4131: use helper function to replace test -f <path>

[Kaartic Sivaraam]

On 19-03-2020 22:12, Shourya Shukla wrote:
> Hello Harshit,
> 
>> Replace 'test -f' with the helper function 'test_path_is_file' as the helper function improves the code readability and also gives better error messages.
> 
> Again the same thing, you may follow what I stated before regarding commit messages.
> 
> The commit title can be of the form:
> 
> t4131: use helpers to replace test -f <path>
> 
> <<commit description>>
> 

Just curious, isn't the commit title already like that in this patch? 
The subject does read:

   [GSoC][PATCH 2/2] t4131: use helper function to replace test -f <path>"

What am I missing?

-- 
Sivaraam

Re: [GSoC][PATCH 2/2] t4131: use helper function to replace test -f <path>

[Harshit Jain]

On Thu, Mar 19, 2020 at 11:04 PM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
>
> On 19-03-2020 22:12, Shourya Shukla wrote:
> > Hello Harshit,
> >
> >> Replace 'test -f' with the helper function 'test_path_is_file' as the helper function improves the code readability and also gives better error messages.
> >
> > Again the same thing, you may follow what I stated before regarding commit messages.
> >
> > The commit title can be of the form:
> >
> > t4131: use helpers to replace test -f <path>
> >
> > <<commit description>>
> >
>
> Just curious, isn't the commit title already like that in this patch?
> The subject does read:
>
>    [GSoC][PATCH 2/2] t4131: use helper function to replace test -f <path>"
>
> What am I missing?
>

Hey Shourya,
Can you please clarify, I am also a bit confused.

Regards,
Harshit Jain

Re: Re: RFC][Feature] submodule

[Shourya Shukla]

Hello Kaartic,

Apologies, I totally missed out on that.

Regards,
Shourya Shukla

Re: [GSoC][PATCH 2/2] t4131: use helper function to replace test -f <path>

[Junio C Hamano]

Shourya Shukla <shouryashukla.oo@gmail.com> writes:

> Hello Harshit,
>
>> Replace 'test -f' with the helper function 'test_path_is_file' as the helper function improves the code readability and also gives better error messages.
>
> Again the same thing, you may follow what I stated before regarding commit messages.
>
> The commit title can be of the form:
>
> t4131: use helpers to replace test -f <path>
>
> <<commit description>>

I think Harshit is writing the title of the commit in the right
place.  Format-wise, the only thing that is wrong is that each
paragraph is too long without line wrapping.

What is wrong in these two e-mail thread is that you are not reading
the log message correctly.  When made into a piece of e-mail, the
title goes to the "Subject:" field in the header and there is no
need to repeat it in the body of the e-mail.

[GSoC][Patch 0/2] made the changes as per community suggestions

[Harshit Jain]

Greetings!

Thank you for suggesting the changes in my patches. I have made the changes
as advised by Junio C Hamano in the following patch emails. Please look into
those patch mails and suggest any further changes if needed.

Thank you once again.

Harshit Jain

[PATCH 1/2] t4131: modernize style

[Harshit Jain]

The tests in t4131 leave a space character between the redirection operator
and the file i.e. the redirection target which does not conform to the
modern coding style.

Fix them.

Signed-off-by: Harshit Jain <harshitjain1371999@gmail.com>
---
 t/t4131-apply-fake-ancestor.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/t4131-apply-fake-ancestor.sh b/t/t4131-apply-fake-ancestor.sh
index b1361ce546..828d1a355b 100755
--- a/t/t4131-apply-fake-ancestor.sh
+++ b/t/t4131-apply-fake-ancestor.sh
@@ -17,8 +17,8 @@ test_expect_success 'setup' '
 
 test_expect_success 'apply --build-fake-ancestor' '
 	git checkout 2 &&
-	echo "A" > 1.t &&
-	git diff > 1.patch &&
+	echo "A" >1.t &&
+	git diff >1.patch &&
 	git reset --hard &&
 	git checkout 1 &&
 	git apply --build-fake-ancestor 1.ancestor 1.patch
@@ -26,8 +26,8 @@ test_expect_success 'apply --build-fake-ancestor' '
 
 test_expect_success 'apply --build-fake-ancestor in a subdirectory' '
 	git checkout 3 &&
-	echo "C" > sub/3.t &&
-	git diff > 3.patch &&
+	echo "C" >sub/3.t &&
+	git diff >3.patch &&
 	git reset --hard &&
 	git checkout 4 &&
 	(
-- 
2.26.0.rc2

Re: Re: [GSoC][Patch]

[Shourya Shukla]

Hello Harshit,

> The tests in t4131 leave a space character between the redirection operator
> and the file i.e. the redirection target which does not conform to the
> modern coding style.

> Fix them.

I think something like,

The tests in t4131 were written a long time ago and hence contain style violations
such as an extra space between the redirection operator(>) and the redirection target.
Update it to match the latest CodingGuidelines.

may be better.

Also, when you deliver a newer version of the patch, i.e., version 2 in your case,
you have a [PATCH v2 1/n] as the subject, so that people know that it is the v2 and
hence avoid confusion.

If you are using 'git format-patch' to formulate your mails, you can do:

'git format-patch -v2 <..>' to get a v2 based mail.

Regards,
Shourya Shukla

Re: Re: [GSoC][Patch]

[Harshit Jain]

Hi Shourya,

On Fri, Mar 20, 2020 at 9:26 PM Shourya Shukla
<shouryashukla.oo@gmail.com> wrote:
>
> Hello Harshit,
>
> > The tests in t4131 leave a space character between the redirection operator
> > and the file i.e. the redirection target which does not conform to the
> > modern coding style.
>
> > Fix them.
>
> I think something like,
>
> The tests in t4131 were written a long time ago and hence contain style violations
> such as an extra space between the redirection operator(>) and the redirection target.
> Update it to match the latest CodingGuidelines.
>
> may be better.
>

Please see the comment made by Junio Hamano, pasted below:

"written a long time ago" does not have much value by itself (it
does serve as a backstory to explain a half of why it does not use
the more modern style, though).  "have a few style violations." is
almost meaningless (otherwise, you would not be doing a "modernize
style" patch in the first place ;-).

I myself also agree with the above comment and hence, wrote the commit message
accordingly. What do you think?

> Also, when you deliver a newer version of the patch, i.e., version 2 in your case,
> you have a [PATCH v2 1/n] as the subject, so that people know that it is the v2 and
> hence avoid confusion.
>
> If you are using 'git format-patch' to formulate your mails, you can do:
>
> 'git format-patch -v2 <..>' to get a v2 based mail.
>

Oh nice, didn't know about this. I will keep this in mind for future
patch submissions.
Should I do this for the current patch as well?

Regards,
Harshit Jain

[PATCH 2/2] t4131: use helper function to replace 'test -f'

[Harshit Jain]

Replace 'test -f' with the helper function 'test_path_is_file' as the
helper function improves the code readability and also gives better
error messages.

Signed-off-by: Harshit Jain <harshitjain1371999@gmail.com>
---
 t/t4131-apply-fake-ancestor.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t4131-apply-fake-ancestor.sh b/t/t4131-apply-fake-ancestor.sh
index 828d1a355b..21ee359632 100755
--- a/t/t4131-apply-fake-ancestor.sh
+++ b/t/t4131-apply-fake-ancestor.sh
@@ -33,7 +33,7 @@ test_expect_success 'apply --build-fake-ancestor in a subdirectory' '
 	(
 		cd sub &&
 		git apply --build-fake-ancestor 3.ancestor ../3.patch &&
-		test -f 3.ancestor
+		test_path_is_file 3.ancestor
 	) &&
 	git apply --build-fake-ancestor 3.ancestor 3.patch &&
 	test_cmp sub/3.ancestor 3.ancestor
-- 
2.26.0.rc2

Re: Re: [GSoC][Patch]

[Shourya Shukla]

Apologies, I totally missed that out for some reason. Silly me! :/

Re: [RFC][Feature] submodule: teach subcommand 'summary' to give summary for nested submodules

[Junio C Hamano]

Shourya Shukla <shouryashukla.oo@gmail.com> writes:

> I was converting the subcommand 'summary'(of command submodule)
> from shell to C and I realised that the subcommand does not have a
> '--recursive' option in it, meaning it cannot give out summaries
> of nested submodules. My opinion on this is that an option should
> maybe exist for the same.
>
> What are the community's thoughts on this? Should the
> aforementioned option be added? Is there any feasibility of this
> option in this case?

If "git submodule summary --recursive" errors out with today's code,
no sane user would be using it for any useful purpose, so I would
think it is OK to add such a feature.

If it makes a usable UI for large projects that you can only choose
between "include no subsubmodules" (i.e. with --no-recursive) or
"include all sub(sub)*modules" (i.e. with --recursive) is another
matter, though.

Re: Re: RFC][Feature] submodule

[Shourya Shukla]

Hello Junio,

> If "git submodule summary --recursive" errors out with today's code,
> no sane user would be using it for any useful purpose, so I would
> think it is OK to add such a feature.

Sure thing! I will try to plan some makeshift implementation.

> If it makes a usable UI for large projects that you can only choose
> between "include no subsubmodules" (i.e. with --no-recursive) or
> "include all sub(sub)*modules" (i.e. with --recursive) is another
> matter, though.

I think discussing this idea may be a good approach right now? What
you are saying for large projects does provoke thought though..
Also, what do you think may become a problem for large projects in
here?

Thank you so much for the feedback BTW :)

Regards,
Shourya Shukla