From: Atharva Raykar <raykar.ath@gmail.com>
To: Shourya Shukla <periperidip@gmail.com>
Cc: git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>,
Christian Couder <christian.couder@gmail.com>,
Prathamesh Chavan <pc44800@gmail.com>
Subject: Re: [PATCH v2] [GSoC] submodule--helper: introduce add-clone subcommand
Date: Fri, 4 Jun 2021 17:32:25 +0530 [thread overview]
Message-ID: <F10D45CC-033E-45F5-B1A6-CA757D3EB6F2@gmail.com> (raw)
In-Reply-To: <CAP6+3T1hN5mvWBe9-hziw=XGOugJ3ah=LVEDwOM5XY2uiZPkOQ@mail.gmail.com>
On 04-Jun-2021, at 17:07, Shourya Shukla <shouryashukla.oo@gmail.com> wrote:
>
> Hi Atharva!
>
> On Wed, Jun 2, 2021 at 6:43 PM Atharva Raykar <raykar.ath@gmail.com> wrote:
>>
>> Let's add a new "add-clone" subcommand to `git submodule--helper` with
>> the goal of converting part of the shell code in git-submodule.sh
>> related to `git submodule add` into C code. This new subcommand clones
>> the repository that is to be added, and checks out to the appropriate
>> branch.
>>
>> This is meant to be a faithful conversion that leaves the behaviour of
>> 'submodule add' unchanged. The only minor change is that if a submodule name has
>> been supplied with a name that clashes with a local submodule, the message shown
>> to the user ("A git directory for 'foo' is found locally...") is prepended with
>> "error" for clarity.
>
> It would be better if commit messages are limited to 72 columns
> (characters) per line.
> Though you can obviously write longer lines on the list no problem.
Good catch. My auto-fill settings had got switched to length 80.
I'll be careful next time.
>> This is part of a series of changes that will result in all of 'submodule add'
>> being converted to C.
>>
>> Signed-off-by: Atharva Raykar <raykar.ath@gmail.com>
>> Mentored-by: Christian Couder <christian.couder@gmail.com>
>> Mentored-by: Shourya Shukla <shouryashukla.oo@gmail.com>
>> Based-on-patch-by: Shourya Shukla <shouryashukla.oo@gmail.com>
>> Based-on-patch-by: Prathamesh Chavan <pc44800@gmail.com>
>
>
> I and others before me used to sign off the previous authors using
> 'Signed-off-by:'. This trailer
> has not been used yet so I am not sure if it should be used though I
> prefer this over the former.
> Maybe Christian could comment here?
Yeah, I wasn't sure if I should include an S.o.B without explicit
acknowledgement from you and Prathamesh.
>> This is part of a series of changes that will result in all of 'submodule add'
>> being converted to C, which is a more familiar language for Git developers, and
>> paves the way to improve performance and portability.
>>
>> I have made this patch based on Shourya's patch[1]. I have decided to send the
>> changes in smaller, more reviewable parts. The add-clone subcommand of
>> submodule--helper is an intermediate change, while I work on translating all of
>> the code.
>>
>> Another subcommand called 'add-config' will also be added in a separate patch
>> that handles the configuration on adding the module.
>>
>> After those two changes look good enough, I will be converting whatever is left
>> of 'git submodule add' in the git-submodule.sh past the flag parsing into C code
>> by having one helper subcommand called 'git submodule--helper add' that will
>> incorporate the functionality of the other two helpers, as well. In that patch,
>> the 'add-clone' and 'add-config' subcommands will be removed from the commands
>> array, as they will be called from within the C code itself.
>
> Seems like a good approach! BTW, if this "extra" message is a bit long
> like the one above, then
> you can put it in a cover letter instead. If people really want to
> read this extra information
> they will read it in a cover letter as well.
>
> Just supply the '--cover-letter' option when executing the 'git
> format-patch' command.
Not too familiar with the convention here on how long a description
warrants a cover letter. Generally in the mailing list I found
[PATCH 0/1] labels far more uncommon than [PATCH] for single patch
changes, so I went with the common case.
>> Changes since v1:
>> * Fixed typos, and made commit message more explicit
>> * Fixed incorrect usage string
>> * Some style changes were made
>
> To save yourself the trouble of sieving the "top" or "noteworthy" changes from
> the new version, you could instead just print the 'range-diff' between
> the two versions.
>
> You can do:
> 'git range-diff b1~n1..b1 b2~n2..b2'
>
> Where:
>
> - 'b1' is the first branch; 'n1' is the number of top commits you are
> taking from 'b1' for
> comparison.
>
> - 'b2' is the second branch; 'n2' is the number of top commits you are
> taking from 'b2' for
> comparison.
>
> It will print a very detailed output showing what differences were
> there commit-wise
> amongst the two branches. This can be put at the end of the cover
> letter. Though, this
> isn't necessary if your way seems better to you.
Thanks for the tip. I felt since this change was mostly about code
style and naming, a range diff for it felt a little extra.
I liked it more when you used it in a previous v2 of your patch,
where the changes were more significant.
> BTW, it would be helpful if you could send mails addressed to me on my
> other email <periperidip@gmail.com>.
Got it.
prev parent reply other threads:[~2021-06-04 12:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-28 8:12 [PATCH][GSoC] submodule: introduce add-clone helper for submodule add Atharva Raykar
2021-06-01 22:10 ` Christian Couder
2021-06-02 7:55 ` Atharva Raykar
2021-06-02 8:18 ` Atharva Raykar
2021-06-02 13:12 ` [PATCH v2] [GSoC] submodule--helper: introduce add-clone subcommand Atharva Raykar
2021-06-04 8:21 ` Christian Couder
2021-06-04 9:47 ` Atharva Raykar
2021-06-04 11:05 ` [PATCH v3] " Atharva Raykar
2021-06-04 11:16 ` Atharva Raykar
2021-06-04 11:37 ` [PATCH v2] " Shourya Shukla
2021-06-04 12:02 ` Atharva Raykar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F10D45CC-033E-45F5-B1A6-CA757D3EB6F2@gmail.com \
--to=raykar.ath@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pc44800@gmail.com \
--cc=periperidip@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).