threads / patch / 47553

patch, 8 partsDoc/submodules: a few updates

Subject: [PATCH 0/8] Doc/submodules: a few updates

## tl;dr

44 messages between Jan 6, 2018 and Jan 17, 2018. Diffs are folded; open one to read it.

replies: 43people: 4as markdown or json

Kaartic Sivaraam· Jan 6, 2018, 18:46 UTC · lore

These are just a few improvements that I thought would make the documentation related to submodules a little better in various way such as readability, consistency etc., These were things I noticed while reading thise documents.

Sorry, for the highly granular patches. I did the commits as and when I was reading them and tried to keep them focused to one particular change by rebasing them as needed. In case they need some change, let me know. 

I based these patches on top of 'master'.

Apart from the changes, I saw a few things that needed improvement/clarification but wasn't able to do that myself due to my limited knowledge of submodules. They are listed below. I'll add in patches for them if they are correctly clarified.

1.
 man gitsubmodules
       ·   The configuration file $GIT_DIR/config in the superproject. Typical configuration at this place is controlling if a submodule is
           recursed into at all via the active flag for example.
           If the submodule is not yet initialized, then the configuration inside the submodule does not exist yet, so configuration where to
           obtain the submodule from is configured here for example.

What's the "active flag" mentioned above? Also I find the phrase "is recursed into at all" to be a little slippery. How could it be improved?

2.
 man git submodule
       update
           ...
           checkout
               ....
               If --force is specified, the submodule will be checked out (using git checkout --force if appropriate), even if the commit
               specified in the index of the containing repository already matches the commit checked out in the submodule.

I'm not sure this is conveying all the information it should be conveying. It seems to making the user wonder, "How at all does 'git submodule update --force' differs from 'git submodule update'?" also "using git checkout --force if appropriate" seems to be invoking all sorts confusion as "appropriate" is superfluous.

How could these confusions be clarified?

--- Kaartic

Kaartic Sivaraam (8):
  Doc/gitsubmodules: split a sentence for better readability
  Doc/gitsubmodules: clearly specify advantage of submodule
  Doc/gitsubmodules: specify how submodules help in reduced size
  Doc/gitsubmodules: avoid abbreviations
  Doc/gitsubmodules: use "Git directory" consistently
  Doc/gitsubmodules: improve readability of certain lines
  Doc/git-submodule: improve readability and grammar of a sentence
  Doc/git-submodule: correctly quote important words
 Documentation/git-submodule.txt | 10 +++++-----
 Documentation/gitsubmodules.txt | 28 ++++++++++++++++------------
 2 files changed, 21 insertions(+), 17 deletions(-)
-- 
2.16.0.rc0.223.g4a4ac8367
Kaartic Sivaraam· Jan 6, 2018, 18:46 UTC · re: Kaartic Sivaraam · lore

[PATCH 1/8] Doc/gitsubmodules: split a sentence for better readability

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/gitsubmodules.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Show changes to Documentation/gitsubmodules.txt +2 −2
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index 46cf120f6..bf46b0fb5 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -36,8 +36,8 @@ The `gitlink` entry contains the object name of the commit that the
 superproject expects the submodule’s working directory to be at.
 
 The section `submodule.foo.*` in the `.gitmodules` file gives additional
-hints to Gits porcelain layer such as where to obtain the submodule via
-the `submodule.foo.url` setting.
+hints to Gits porcelain layer. For example, the `submodule.foo.url`
+setting specifies where to obtain the submodule.
 
 Submodules can be used for at least two different use cases:
 

-- 
2.16.0.rc0.223.g4a4ac8367
Eric Sunshine· Jan 7, 2018, 00:29 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 1/8] Doc/gitsubmodules: split a sentence for better readability

On Sat, Jan 6, 2018 at 1:46 PM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 9 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> @@ -36,8 +36,8 @@ The `gitlink` entry contains the object name of the commit that the
>  The section `submodule.foo.*` in the `.gitmodules` file gives additional
> -hints to Gits porcelain layer such as where to obtain the submodule via
> -the `submodule.foo.url` setting.
> +hints to Gits porcelain layer. For example, the `submodule.foo.url`
> +setting specifies where to obtain the submodule.

I don't find the original difficult to read (aside, perhaps, from the missing comma before "such as"), so I don't feel strongly about this change.

However, since you're touching this, you could apply the s/Gits/Git's/ fix.
Stefan Beller· Jan 8, 2018, 18:33 UTC · re: Eric Sunshine · lore

Re: [PATCH 1/8] Doc/gitsubmodules: split a sentence for better readability

On Sat, Jan 6, 2018 at 4:29 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 15 quoted lines
> On Sat, Jan 6, 2018 at 1:46 PM, Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> wrote:
>> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
>> ---
>> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
>> @@ -36,8 +36,8 @@ The `gitlink` entry contains the object name of the commit that the
>>  The section `submodule.foo.*` in the `.gitmodules` file gives additional
>> -hints to Gits porcelain layer such as where to obtain the submodule via
>> -the `submodule.foo.url` setting.
>> +hints to Gits porcelain layer. For example, the `submodule.foo.url`
>> +setting specifies where to obtain the submodule.
>
> I don't find the original difficult to read (aside, perhaps, from the
> missing comma before "such as"), so I don't feel strongly about this
> change.

Seconded. I am neutral to this change, but as you were keen enough to come up with the patch, I see no reason to reject it. Anyway, let's read on!

Thanks, Stefan

>
> However, since you're touching this, you could apply the s/Gits/Git's/ fix.
Kaartic Sivaraam· Jan 6, 2018, 18:46 UTC · re: Kaartic Sivaraam · lore

[PATCH 2/8] Doc/gitsubmodules: clearly specify advantage of submodule

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/gitsubmodules.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to Documentation/gitsubmodules.txt +1 −1
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index bf46b0fb5..cb795c6b6 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -57,7 +57,7 @@ Submodules can be used for at least two different use cases:
     * Size of the git repository:
       In its current form Git scales up poorly for large repositories containing
       content that is not compressed by delta computation between trees.
-      However you can also use submodules to e.g. hold large binary assets
+      Therefore you can use submodules to hold large binary assets
       and these repositories are then shallowly cloned such that you do not
       have a large history locally.
     * Transfer size:

-- 
2.16.0.rc0.223.g4a4ac8367
Stefan Beller· Jan 8, 2018, 18:36 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 2/8] Doc/gitsubmodules: clearly specify advantage of submodule

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 15 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
>  Documentation/gitsubmodules.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> index bf46b0fb5..cb795c6b6 100644
> --- a/Documentation/gitsubmodules.txt
> +++ b/Documentation/gitsubmodules.txt
> @@ -57,7 +57,7 @@ Submodules can be used for at least two different use cases:
>      * Size of the git repository:
>        In its current form Git scales up poorly for large repositories containing
>        content that is not compressed by delta computation between trees.
> -      However you can also use submodules to e.g. hold large binary assets
> +      Therefore you can use submodules to hold large binary assets

If this improves readability by a lot, I'd be all for it. But this use case is just exemplary. There are also cases of submodules that do not contain big files, but e.g. have a lengthy history with lots of small files. So I don't know, as I would want to keep emphasized that this is just an example.

Show 6 quoted lines
>        and these repositories are then shallowly cloned such that you do not
>        have a large history locally.
>      * Transfer size:
> --
> 2.16.0.rc0.223.g4a4ac8367
>
Kaartic Sivaraam· Jan 9, 2018, 15:58 UTC · re: Stefan Beller · lore

Re: [PATCH 2/8] Doc/gitsubmodules: clearly specify advantage of submodule

Show 11 quoted lines
>>        content that is not compressed by delta computation between trees.
>> -      However you can also use submodules to e.g. hold large binary assets
>> +      Therefore you can use submodules to hold large binary assets
> 
> If this improves readability by a lot, I'd be all for it. But this use
> case is just
> exemplary. There are also cases of submodules that do not contain big files,
> but e.g. have a lengthy history with lots of small files.
> So I don't know, as I would want to keep emphasized that this is just
> an example.
>

You're right I actually screwed up by emphasizing that was the only use case it was envisioned for. Fixed it by replacing "Therefore" with " For example, ..."

Thanks, Kaartic

Kaartic Sivaraam· Jan 6, 2018, 18:46 UTC · re: Kaartic Sivaraam · lore

[PATCH 3/8] Doc/gitsubmodules: specify how submodules help in reduced size

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/gitsubmodules.txt | 3 +++
 1 file changed, 3 insertions(+)
Show changes to Documentation/gitsubmodules.txt +3 −0
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index cb795c6b6..3f73983d5 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -63,6 +63,9 @@ Submodules can be used for at least two different use cases:
     * Transfer size:
       In its current form Git requires the whole working tree present. It
       does not allow partial trees to be transferred in fetch or clone.
+      If you have your project as multiple repositories tied together as
+      submodules in a superproject, you can avoid fetching the working
+      trees of the repositories you are not interested in.
     * Access control:
       By restricting user access to submodules, this can be used to implement
       read/write policies for different users.

-- 
2.16.0.rc0.223.g4a4ac8367
Eric Sunshine· Jan 7, 2018, 00:31 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 3/8] Doc/gitsubmodules: specify how submodules help in reduced size

On Sat, Jan 6, 2018 at 1:46 PM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 10 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> @@ -63,6 +63,9 @@ Submodules can be used for at least two different use cases:
>      * Transfer size:
>        In its current form Git requires the whole working tree present. It
>        does not allow partial trees to be transferred in fetch or clone.
> +      If you have your project as multiple repositories tied together as
> +      submodules in a superproject, you can avoid fetching the working
> +      trees of the repositories you are not interested in.
"If your project consists of multiple repositories tied together..."
Stefan Beller· Jan 8, 2018, 18:38 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 3/8] Doc/gitsubmodules: specify how submodules help in reduced size

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 16 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
>  Documentation/gitsubmodules.txt | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> index cb795c6b6..3f73983d5 100644
> --- a/Documentation/gitsubmodules.txt
> +++ b/Documentation/gitsubmodules.txt
> @@ -63,6 +63,9 @@ Submodules can be used for at least two different use cases:
>      * Transfer size:
>        In its current form Git requires the whole working tree present. It
>        does not allow partial trees to be transferred in fetch or clone.
> +      If you have your project as multiple repositories tied together as
> +      submodules in a superproject, you can avoid fetching the working
> +      trees of the repositories you are not interested in.
You do not fetch a working tree, but a whole repository?
Show 6 quoted lines
>      * Access control:
>        By restricting user access to submodules, this can be used to implement
>        read/write policies for different users.
> --
> 2.16.0.rc0.223.g4a4ac8367
>
Kaartic Sivaraam· Jan 9, 2018, 16:01 UTC · re: Stefan Beller · lore

Re: [PATCH 3/8] Doc/gitsubmodules: specify how submodules help in reduced size

On Tuesday 09 January 2018 12:08 AM, Stefan Beller wrote:
Show 14 quoted lines
>> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
>> index cb795c6b6..3f73983d5 100644
>> --- a/Documentation/gitsubmodules.txt
>> +++ b/Documentation/gitsubmodules.txt
>> @@ -63,6 +63,9 @@ Submodules can be used for at least two different use cases:
>>      * Transfer size:
>>        In its current form Git requires the whole working tree present. It
>>        does not allow partial trees to be transferred in fetch or clone.
>> +      If you have your project as multiple repositories tied together as
>> +      submodules in a superproject, you can avoid fetching the working
>> +      trees of the repositories you are not interested in.
> 
> You do not fetch a working tree, but a whole repository?
>

Maybe I misunderstood submodules when I wrote that example. Could you help out with a better and precise replacement?

Just putting in some context as to why I did this change, I thought this was the only thing that lacked an example and wanted to make it consistent.

-- 
Kaartic
Stefan Beller· Jan 9, 2018, 19:01 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 3/8] Doc/gitsubmodules: specify how submodules help in reduced size

On Tue, Jan 9, 2018 at 8:01 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 18 quoted lines
> On Tuesday 09 January 2018 12:08 AM, Stefan Beller wrote:
>>> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
>>> index cb795c6b6..3f73983d5 100644
>>> --- a/Documentation/gitsubmodules.txt
>>> +++ b/Documentation/gitsubmodules.txt
>>> @@ -63,6 +63,9 @@ Submodules can be used for at least two different use cases:
>>>      * Transfer size:
>>>        In its current form Git requires the whole working tree present. It
>>>        does not allow partial trees to be transferred in fetch or clone.
>>> +      If you have your project as multiple repositories tied together as
>>> +      submodules in a superproject, you can avoid fetching the working
>>> +      trees of the repositories you are not interested in.
>>
>> You do not fetch a working tree, but a whole repository?
>>
>
> Maybe I misunderstood submodules when I wrote that example. Could you
> help out with a better and precise replacement?

If your project consists of multiple repositories tied together, some submodules may not be of interest for all users, who do not need to fetch such submodule repositories.

> Just putting in some context as to why I did this change, I thought this
> was the only thing that lacked an example and wanted to make it consistent.

Oh, sure I like the example; I was just worried about the wording, as a worktree is part of a repository, and the repository is the whole thing. In the current situation you can only fetch all-or-nothing, specifically you cannot fetch "just the worktree" (a shallow clone/fetch is the closest to that, but that still has the same amount of information the .git dir, than in the working tree)

Kaartic Sivaraam· Jan 9, 2018, 19:30 UTC · re: Stefan Beller · lore

Re: [PATCH 3/8] Doc/gitsubmodules: specify how submodules help in reduced size

On Wednesday 10 January 2018 12:31 AM, Stefan Beller wrote:
Show 25 quoted lines
> On Tue, Jan 9, 2018 at 8:01 AM, Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> wrote:
>> On Tuesday 09 January 2018 12:08 AM, Stefan Beller wrote:
>>>> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
>>>> index cb795c6b6..3f73983d5 100644
>>>> --- a/Documentation/gitsubmodules.txt
>>>> +++ b/Documentation/gitsubmodules.txt
>>>> @@ -63,6 +63,9 @@ Submodules can be used for at least two different use cases:
>>>>      * Transfer size:
>>>>        In its current form Git requires the whole working tree present. It
>>>>        does not allow partial trees to be transferred in fetch or clone.
>>>> +      If you have your project as multiple repositories tied together as
>>>> +      submodules in a superproject, you can avoid fetching the working
>>>> +      trees of the repositories you are not interested in.
>>>
>>> You do not fetch a working tree, but a whole repository?
>>>
>>
>> Maybe I misunderstood submodules when I wrote that example. Could you
>> help out with a better and precise replacement?
> 
> If your project consists of multiple repositories tied together, some submodules
> may not be of interest for all users, who do not need to fetch such submodule
> repositories.
>

OK, now I get why I couldn't get your point. I actually was thinking of the version of the message I had tweaked for v2 when reading your message. It doesn't have the confusing meaning. It actually reads,

   ...
   If the project you work on consists of multiple repositories tied
   together as submodules in a superproject, you can avoid fetching the
   working trees of the repositories you are not interested in.

So, my version takes the perspective of the person who gains the advantage of having to clone unnecessary repos. And yours, the perspective of the person who gives the consumer of the repo that advantage. Both sound nice to me. But if mine doesn't sound nice to you, let me know so that I could replace it with your version.

Show 12 quoted lines
>> Just putting in some context as to why I did this change, I thought this
>> was the only thing that lacked an example and wanted to make it consistent.
> 
> Oh, sure I like the example; I was just worried about the wording, as a worktree
> is part of a repository, and the repository is the whole thing. In the
> current situation
> you can only fetch all-or-nothing, specifically you cannot fetch "just
> the worktree"
> (a shallow clone/fetch is the closest to that, but that still has the
> same amount of
> information the .git dir, than in the working tree)
> 
I get that!
Kaartic Sivaraam· Jan 6, 2018, 18:46 UTC · re: Kaartic Sivaraam · lore

[PATCH 4/8] Doc/gitsubmodules: avoid abbreviations

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/gitsubmodules.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
Show changes to Documentation/gitsubmodules.txt +3 −3
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index 3f73983d5..e3c798d2a 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -76,9 +76,9 @@ The configuration of submodules
 Submodule operations can be configured using the following mechanisms
 (from highest to lowest precedence):
 
- * The command line for those commands that support taking submodule specs.
-   Most commands have a boolean flag '--recurse-submodules' whether to
-   recurse into submodules. Examples are `ls-files` or `checkout`.
+ * The command line for those commands that support taking submodule
+   specifications. Most commands have a boolean flag '--recurse-submodules
+   whether to recurse into submodules. Examples are `ls-files` or `checkout`.
    Some commands take enums, such as `fetch` and `push`, where you can
    specify how submodules are affected.
 

-- 
2.16.0.rc0.223.g4a4ac8367
Eric Sunshine· Jan 7, 2018, 00:36 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 4/8] Doc/gitsubmodules: avoid abbreviations

On Sat, Jan 6, 2018 at 1:46 PM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 10 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> @@ -76,9 +76,9 @@ The configuration of submodules
> - * The command line for those commands that support taking submodule specs.
> -   Most commands have a boolean flag '--recurse-submodules' whether to
> -   recurse into submodules. Examples are `ls-files` or `checkout`.
> + * The command line for those commands that support taking submodule
> +   specifications. Most commands have a boolean flag '--recurse-submodules
> +   whether to recurse into submodules. Examples are `ls-files` or `checkout`.
Your change loses the closing quote on --recurse-submodules.

Also, since you're touching this, it wouldn't hurt to address the grammatical shortcoming(s), as well. To wit: Something is missing between "--recurse-submodules" and "whether".

Stefan Beller· Jan 8, 2018, 18:45 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 4/8] Doc/gitsubmodules: avoid abbreviations

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 14 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
>  Documentation/gitsubmodules.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> index 3f73983d5..e3c798d2a 100644
> --- a/Documentation/gitsubmodules.txt
> +++ b/Documentation/gitsubmodules.txt
> @@ -76,9 +76,9 @@ The configuration of submodules
>  Submodule operations can be configured using the following mechanisms
>  (from highest to lowest precedence):
>
> - * The command line for those commands that support taking submodule specs.

++ The command line for those commands that support taking submodules as part of their pathspecs[1]. ++ ++[1] pathspec is an official term according to `man gitglossary`.

Maybe?
Show 11 quoted lines
> -   Most commands have a boolean flag '--recurse-submodules' whether to
> -   recurse into submodules. Examples are `ls-files` or `checkout`.
> + * The command line for those commands that support taking submodule
> +   specifications. Most commands have a boolean flag '--recurse-submodules
> +   whether to recurse into submodules. Examples are `ls-files` or `checkout`.
>     Some commands take enums, such as `fetch` and `push`, where you can
>     specify how submodules are affected.
>
> --
> 2.16.0.rc0.223.g4a4ac8367
>
Kaartic Sivaraam· Jan 9, 2018, 16:06 UTC · re: Stefan Beller · lore

Re: [PATCH 4/8] Doc/gitsubmodules: avoid abbreviations

On Tuesday 09 January 2018 12:15 AM, Stefan Beller wrote:
Show 10 quoted lines
>>
>> - * The command line for those commands that support taking submodule specs.
> 
> ++ The command line for those commands that support taking submodules
> as part of their pathspecs[1].
> ++
> ++[1] pathspec is an official term according to `man gitglossary`.
> 
> Maybe?
>

Yeah, I actually did think 'specification' wasn't a the best fit for this (should have mentioned that somewhere) Now, the real term came out :)

Just to be sure, that "[1] pathspec ..." part goes to the end of the document doesn't it?

Show 11 quoted lines
>> -   Most commands have a boolean flag '--recurse-submodules' whether to
>> -   recurse into submodules. Examples are `ls-files` or `checkout`.
>> + * The command line for those commands that support taking submodule
>> +   specifications. Most commands have a boolean flag '--recurse-submodules
>> +   whether to recurse into submodules. Examples are `ls-files` or `checkout`.
>>     Some commands take enums, such as `fetch` and `push`, where you can
>>     specify how submodules are affected.
>>
>> --
>> 2.16.0.rc0.223.g4a4ac8367
>>
Stefan Beller· Jan 9, 2018, 19:26 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 4/8] Doc/gitsubmodules: avoid abbreviations

On Tue, Jan 9, 2018 at 8:06 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 17 quoted lines
> On Tuesday 09 January 2018 12:15 AM, Stefan Beller wrote:
>>>
>>> - * The command line for those commands that support taking submodule specs.
>>
>> ++ The command line for those commands that support taking submodules
>> as part of their pathspecs[1].
>> ++
>> ++[1] pathspec is an official term according to `man gitglossary`.
>>
>> Maybe?
>>
>
> Yeah, I actually did think 'specification' wasn't a the best fit for
> this (should have mentioned that somewhere) Now, the real term came out :)
>
> Just to be sure, that "[1] pathspec ..." part goes to the end of the
> document doesn't it?

The [1] part was just to highlight it for the sake of this discussion; I would not include it into the man page.

Stefan
Kaartic Sivaraam· Jan 9, 2018, 19:32 UTC · re: Stefan Beller · lore

Re: [PATCH 4/8] Doc/gitsubmodules: avoid abbreviations

On Wednesday 10 January 2018 12:56 AM, Stefan Beller wrote:
Show 23 quoted lines
> On Tue, Jan 9, 2018 at 8:06 AM, Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> wrote:
>> On Tuesday 09 January 2018 12:15 AM, Stefan Beller wrote:
>>>>
>>>> - * The command line for those commands that support taking submodule specs.
>>>
>>> ++ The command line for those commands that support taking submodules
>>> as part of their pathspecs[1].
>>> ++
>>> ++[1] pathspec is an official term according to `man gitglossary`.
>>>
>>> Maybe?
>>>
>>
>> Yeah, I actually did think 'specification' wasn't a the best fit for
>> this (should have mentioned that somewhere) Now, the real term came out :)
>>
>> Just to be sure, that "[1] pathspec ..." part goes to the end of the
>> document doesn't it?
> 
> The [1] part was just to highlight it for the sake of this discussion;
> I would not include it into the man page.
> 
That '++' before it made me think otherwise :)
Kaartic Sivaraam· Jan 6, 2018, 18:46 UTC · re: Kaartic Sivaraam · lore

[PATCH 5/8] Doc/gitsubmodules: use "Git directory" consistently

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/gitsubmodules.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to Documentation/gitsubmodules.txt +1 −1
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index e3c798d2a..745a3838e 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -113,7 +113,7 @@ obtain the submodule from is configured here for example.
    of repositories.
 +
 This file mainly serves as the mapping between name and path in
-the superproject, such that the submodule's git directory can be
+the superproject, such that the submodule's Git directory can be
 located.
 +
 If the submodule has never been initialized, this is the only place

-- 
2.16.0.rc0.223.g4a4ac8367
Eric Sunshine· Jan 7, 2018, 00:39 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 5/8] Doc/gitsubmodules: use "Git directory" consistently

On Sat, Jan 6, 2018 at 1:46 PM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 8 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> @@ -113,7 +113,7 @@ obtain the submodule from is configured here for example.
>  This file mainly serves as the mapping between name and path in
> -the superproject, such that the submodule's git directory can be
> +the superproject, such that the submodule's Git directory can be
>  located.

There are two more instances of this capitalization inconsistency later in the file. This patch probably ought to address all of them.

Stefan Beller· Jan 8, 2018, 18:45 UTC · re: Eric Sunshine · lore

Re: [PATCH 5/8] Doc/gitsubmodules: use "Git directory" consistently

On Sat, Jan 6, 2018 at 4:39 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 13 quoted lines
> On Sat, Jan 6, 2018 at 1:46 PM, Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> wrote:
>> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
>> ---
>> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
>> @@ -113,7 +113,7 @@ obtain the submodule from is configured here for example.
>>  This file mainly serves as the mapping between name and path in
>> -the superproject, such that the submodule's git directory can be
>> +the superproject, such that the submodule's Git directory can be
>>  located.
>
> There are two more instances of this capitalization inconsistency
> later in the file. This patch probably ought to address all of them.
Thanks for fixing the capitalization!
Kaartic Sivaraam· Jan 6, 2018, 18:46 UTC · re: Kaartic Sivaraam · lore

[PATCH 6/8] Doc/gitsubmodules: improve readability of certain lines

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/gitsubmodules.txt | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)
Show changes to Documentation/gitsubmodules.txt +10 −9
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index 745a3838e..339fb73db 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -76,9 +76,10 @@ The configuration of submodules
 Submodule operations can be configured using the following mechanisms
 (from highest to lowest precedence):
 
- * The command line for those commands that support taking submodule
-   specifications. Most commands have a boolean flag '--recurse-submodules
-   whether to recurse into submodules. Examples are `ls-files` or `checkout`.
+ * The command line arguments of those commands that support taking submodule
+   specifications. Most commands have a boolean flag '--recurse-submodules'
+   which specify whether they should recurse into submodules. Examples are
+   `ls-files` or `checkout`.
    Some commands take enums, such as `fetch` and `push`, where you can
    specify how submodules are affected.
 
@@ -90,8 +91,8 @@ Submodule operations can be configured using the following mechanisms
 For example an effect from the submodule's `.gitignore` file
 would be observed when you run `git status --ignore-submodules=none` in
 the superproject. This collects information from the submodule's working
-directory by running `status` in the submodule, which does pay attention
-to its `.gitignore` file.
+directory by running `status` in the submodule while paying attention
+to the `.gitignore` file of the submodule.
 +
 The submodule's `$GIT_DIR/config` file would come into play when running
 `git push --recurse-submodules=check` in the superproject, as this would
@@ -107,13 +108,13 @@ If the submodule is not yet initialized, then the configuration
 inside the submodule does not exist yet, so configuration where to
 obtain the submodule from is configured here for example.
 
- * the `.gitmodules` file inside the superproject. Additionally to the
-   required mapping between submodule's name and path, a project usually
+ * The `.gitmodules` file inside the superproject. Additionally, if mapping
+   is required between a submodule's name and its path, a project usually
    uses this file to suggest defaults for the upstream collection
    of repositories.
 +
-This file mainly serves as the mapping between name and path in
-the superproject, such that the submodule's Git directory can be
+This file mainly serves as the mapping between the name and path of submodules
+in the superproject, such that the submodule's Git directory can be
 located.
 +
 If the submodule has never been initialized, this is the only place

-- 
2.16.0.rc0.223.g4a4ac8367
Eric Sunshine· Jan 7, 2018, 00:44 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 6/8] Doc/gitsubmodules: improve readability of certain lines

On Sat, Jan 6, 2018 at 1:46 PM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 11 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> @@ -76,9 +76,10 @@ The configuration of submodules
> - * The command line for those commands that support taking submodule
> -   specifications. Most commands have a boolean flag '--recurse-submodules
> -   whether to recurse into submodules. Examples are `ls-files` or `checkout`.
> + * The command line arguments of those commands that support taking submodule
> +   specifications. Most commands have a boolean flag '--recurse-submodules'
> +   which specify whether they should recurse into submodules. Examples are
> +   `ls-files` or `checkout`.

So, this is addressing issues pointed out in my review of 4/8. It's actually fixing a problem -- missing closing quote -- introduced by 4/8. Therefore, it probably would make sense either to move this hunk into 4/8 or drop 4/8 altogether.

Stefan Beller· Jan 8, 2018, 18:49 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 6/8] Doc/gitsubmodules: improve readability of certain lines

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 31 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
>  Documentation/gitsubmodules.txt | 19 ++++++++++---------
>  1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> index 745a3838e..339fb73db 100644
> --- a/Documentation/gitsubmodules.txt
> +++ b/Documentation/gitsubmodules.txt
> @@ -76,9 +76,10 @@ The configuration of submodules
>  Submodule operations can be configured using the following mechanisms
>  (from highest to lowest precedence):
>
> - * The command line for those commands that support taking submodule
> -   specifications. Most commands have a boolean flag '--recurse-submodules
> -   whether to recurse into submodules. Examples are `ls-files` or `checkout`.
> + * The command line arguments of those commands that support taking submodule
> +   specifications. Most commands have a boolean flag '--recurse-submodules'
> +   which specify whether they should recurse into submodules. Examples are
> +   `ls-files` or `checkout`.
>     Some commands take enums, such as `fetch` and `push`, where you can
>     specify how submodules are affected.
>
> @@ -90,8 +91,8 @@ Submodule operations can be configured using the following mechanisms
>  For example an effect from the submodule's `.gitignore` file
>  would be observed when you run `git status --ignore-submodules=none` in
>  the superproject. This collects information from the submodule's working
> -directory by running `status` in the submodule, which does pay attention
> -to its `.gitignore` file.
> +directory by running `status` in the submodule while paying attention
> +to the `.gitignore` file of the submodule.
Both are grammatically correct and expressive, thanks!
>  +
Extra spurious line?
Show 10 quoted lines
>  The submodule's `$GIT_DIR/config` file would come into play when running
>  `git push --recurse-submodules=check` in the superproject, as this would
> @@ -107,13 +108,13 @@ If the submodule is not yet initialized, then the configuration
>  inside the submodule does not exist yet, so configuration where to
>  obtain the submodule from is configured here for example.
>
> - * the `.gitmodules` file inside the superproject. Additionally to the
> -   required mapping between submodule's name and path, a project usually
> + * The `.gitmodules` file inside the superproject. Additionally, if mapping
> +   is required between a submodule's name and its path, a project usually
This changes meaning, originally it tries to say:
* it requires mapping path <-> names.
* but there can be more.
whereas the new lines are:
* mapping is optional
* there can be more.
Show 8 quoted lines
>     uses this file to suggest defaults for the upstream collection
>     of repositories.
>  +
> -This file mainly serves as the mapping between name and path in
> -the superproject, such that the submodule's Git directory can be
> +This file mainly serves as the mapping between the name and path of submodules
> +in the superproject, such that the submodule's Git directory can be
>  located.
makes sense!

Thanks, Stefan

Show 5 quoted lines
>  +
>  If the submodule has never been initialized, this is the only place
> --
> 2.16.0.rc0.223.g4a4ac8367
>
Kaartic Sivaraam· Jan 9, 2018, 16:37 UTC · re: Stefan Beller · lore

Re: [PATCH 6/8] Doc/gitsubmodules: improve readability of certain lines

On Tuesday 09 January 2018 12:19 AM, Stefan Beller wrote:
Show 24 quoted lines
> On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> wrote:
>>
>> - * The command line for those commands that support taking submodule
>> -   specifications. Most commands have a boolean flag '--recurse-submodules
>> -   whether to recurse into submodules. Examples are `ls-files` or `checkout`.
>> + * The command line arguments of those commands that support taking submodule
>> +   specifications. Most commands have a boolean flag '--recurse-submodules'
>> +   which specify whether they should recurse into submodules. Examples are
>> +   `ls-files` or `checkout`.
>>     Some commands take enums, such as `fetch` and `push`, where you can
>>     specify how submodules are affected.
>>
>> @@ -90,8 +91,8 @@ Submodule operations can be configured using the following mechanisms
>>  For example an effect from the submodule's `.gitignore` file
>>  would be observed when you run `git status --ignore-submodules=none` in
>>  the superproject. This collects information from the submodule's working
>> -directory by running `status` in the submodule, which does pay attention
>> -to its `.gitignore` file.
>> +directory by running `status` in the submodule while paying attention
>> +to the `.gitignore` file of the submodule.
> 
> Both are grammatically correct and expressive, thanks!
>
You're welcome!
>>  +
> 
> Extra spurious line?
>

No. That's a "real" plus in the document that's usually present between paragraphs :) I think I now get why Junio suggests people to review patches in context (possibly, by applying them) ;)

Show 6 quoted lines
>>  The submodule's `$GIT_DIR/config` file would come into play when running
>>  `git push --recurse-submodules=check` in the superproject, as this would
>> @@ -107,13 +108,13 @@ If the submodule is not yet initialized, then the configuration
>>  inside the submodule does not exist yet, so configuration where to
>>  obtain the submodule from is configured here for example.
>>

I caught this in the context while replying. "so configuration where to obtain the submodule from is configured here for example." doesn't seem to read well. Maybe removing configuration from the sentence will make it sound better?

Show 8 quoted lines
>> - * the `.gitmodules` file inside the superproject. Additionally to the
>> -   required mapping between submodule's name and path, a project usually
>> + * The `.gitmodules` file inside the superproject. Additionally, if mapping
>> +   is required between a submodule's name and its path, a project usually
> 
> This changes meaning, originally it tries to say:
> 
> * it requires mapping path <-> names.
I get this ...
> * but there can be more.
>

... but not this. Did the previous version really try to say this? Anyways how does this sound?

  * The `.gitmodules` file inside the superproject. A project usually
    uses this file to suggest defaults for the upstream collection
    of repositories for the mapping that is required between a
    submodule's name and its path.

I think it conveys the "it requires mapping path <-> names." correctly but doesn't convey the "but there can be more." part. I'm not sure how to get that into the sentence, correctly.

Stefan Beller· Jan 9, 2018, 19:31 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 6/8] Doc/gitsubmodules: improve readability of certain lines

Show 28 quoted lines
>>>  The submodule's `$GIT_DIR/config` file would come into play when running
>>>  `git push --recurse-submodules=check` in the superproject, as this would
>>> @@ -107,13 +108,13 @@ If the submodule is not yet initialized, then the configuration
>>>  inside the submodule does not exist yet, so configuration where to
>>>  obtain the submodule from is configured here for example.
>>>
>
> I caught this in the context while replying. "so configuration where to
> obtain the submodule from is configured here for example." doesn't seem
> to read well. Maybe removing configuration from the sentence will make
> it sound better?
>
>
>>> - * the `.gitmodules` file inside the superproject. Additionally to the
>>> -   required mapping between submodule's name and path, a project usually
>>> + * The `.gitmodules` file inside the superproject. Additionally, if mapping
>>> +   is required between a submodule's name and its path, a project usually
>>
>> This changes meaning, originally it tries to say:
>>
>> * it requires mapping path <-> names.
>
> I get this ...
>
>> * but there can be more.
>
> ... but not this. Did the previous version really try to say this?
> Anyways how does this sound?

Well that was me being very sloppy trying to say that there might be submodule.<name>.{url, ignored, shallow} settings which just happen to be there.

Show 8 quoted lines
>   * The `.gitmodules` file inside the superproject. A project usually
>     uses this file to suggest defaults for the upstream collection
>     of repositories for the mapping that is required between a
>     submodule's name and its path.
>
> I think it conveys the "it requires mapping path <-> names." correctly
> but doesn't convey the "but there can be more." part. I'm not sure how
> to get that into the sentence, correctly.

I did not consider that part the important part, hence my sloppiness. Sorry for the confusion.

My main point was to say that the mapping is the important part and must be found in the .gitmodules file, otherwise we do not consider it a submodule (for whatever "it" is, maybe a gitlink at a path=name).

Stefan
Kaartic Sivaraam· Jan 9, 2018, 19:57 UTC · re: Stefan Beller · lore

Re: [PATCH 6/8] Doc/gitsubmodules: improve readability of certain lines

On Wednesday 10 January 2018 01:01 AM, Stefan Beller wrote:
Show 12 quoted lines
>>>>  The submodule's `$GIT_DIR/config` file would come into play when running
>>>>  `git push --recurse-submodules=check` in the superproject, as this would
>>>> @@ -107,13 +108,13 @@ If the submodule is not yet initialized, then the configuration
>>>>  inside the submodule does not exist yet, so configuration where to
>>>>  obtain the submodule from is configured here for example.
>>>>
>>
>> I caught this in the context while replying. "so configuration where to
>> obtain the submodule from is configured here for example." doesn't seem
>> to read well. Maybe removing configuration from the sentence will make
>> it sound better?
>>
I'm going to make this change.
Show 37 quoted lines
>>
>>>> - * the `.gitmodules` file inside the superproject. Additionally to the
>>>> -   required mapping between submodule's name and path, a project usually
>>>> + * The `.gitmodules` file inside the superproject. Additionally, if mapping
>>>> +   is required between a submodule's name and its path, a project usually
>>>
>>> This changes meaning, originally it tries to say:
>>>
>>> * it requires mapping path <-> names.
>>
>> I get this ...
>>
>>> * but there can be more.
>>
>> ... but not this. Did the previous version really try to say this?
>> Anyways how does this sound?
> 
> Well that was me being very sloppy trying to say that there might be
> submodule.<name>.{url, ignored, shallow} settings which just happen to
> be there.
> 
>>   * The `.gitmodules` file inside the superproject. A project usually
>>     uses this file to suggest defaults for the upstream collection
>>     of repositories for the mapping that is required between a
>>     submodule's name and its path.
>>
>> I think it conveys the "it requires mapping path <-> names." correctly
>> but doesn't convey the "but there can be more." part. I'm not sure how
>> to get that into the sentence, correctly.
> 
> I did not consider that part the important part, hence my sloppiness.
> Sorry for the confusion.
> 
> My main point was to say that the mapping is the important part and
> must be found in the .gitmodules file, otherwise we do not consider
> it a submodule (for whatever "it" is, maybe a gitlink at a path=name).
>

So, I'm going to use the version that I specified above as I think it seems to convey that clearly (at least to me),

    The `.gitmodules` file inside the superproject. A project usually
    uses this file to suggest defaults for the upstream collection
    of repositories for the mapping that is required between a
    submodule's name and its path.
Let me know, if there are issues.

Thanks, Kaartic

Kaartic Sivaraam· Jan 6, 2018, 18:46 UTC · re: Kaartic Sivaraam · lore

[PATCH 7/8] Doc/git-submodule: improve readability and grammar of a sentence

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/git-submodule.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
Show changes to Documentation/git-submodule.txt +3 −3
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index ff612001d..befbccde6 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -132,9 +132,9 @@ expects by cloning missing submodules and updating the working tree of
 the submodules. The "updating" can be done in several ways depending
 on command line options and the value of `submodule.<name>.update`
 configuration variable. The command line option takes precedence over
-the configuration variable. if neither is given, a checkout is performed.
-update procedures supported both from the command line as well as setting
-`submodule.<name>.update`:
+the configuration variable. If neither is given, a checkout is performed.
+The update procedures supported both from the command line as well as
+through the `submodule.<name>.update` configuration are:
 
 	checkout;; the commit recorded in the superproject will be
 	    checked out in the submodule on a detached HEAD.

-- 
2.16.0.rc0.223.g4a4ac8367
Stefan Beller· Jan 8, 2018, 18:57 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 7/8] Doc/git-submodule: improve readability and grammar of a sentence

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 19 quoted lines
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
>  Documentation/git-submodule.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index ff612001d..befbccde6 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -132,9 +132,9 @@ expects by cloning missing submodules and updating the working tree of
>  the submodules. The "updating" can be done in several ways depending
>  on command line options and the value of `submodule.<name>.update`
>  configuration variable. The command line option takes precedence over
> -the configuration variable. if neither is given, a checkout is performed.
> -update procedures supported both from the command line as well as setting
> -`submodule.<name>.update`:
> +the configuration variable. If neither is given, a checkout is performed.
> +The update procedures supported both from the command line as well as
> +through the `submodule.<name>.update` configuration are:

Makes sense! Thanks, Stefan

Show 6 quoted lines
>
>         checkout;; the commit recorded in the superproject will be
>             checked out in the submodule on a detached HEAD.
> --
> 2.16.0.rc0.223.g4a4ac8367
>
Kaartic Sivaraam· Jan 6, 2018, 18:46 UTC · re: Kaartic Sivaraam · lore

[PATCH 8/8] Doc/git-submodule: correctly quote important words

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/git-submodule.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
Show changes to Documentation/git-submodule.txt +4 −4
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index befbccde6..5c4d941cc 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -132,8 +132,8 @@ expects by cloning missing submodules and updating the working tree of
 the submodules. The "updating" can be done in several ways depending
 on command line options and the value of `submodule.<name>.update`
 configuration variable. The command line option takes precedence over
-the configuration variable. If neither is given, a checkout is performed.
-The update procedures supported both from the command line as well as
+the configuration variable. If neither is given, a 'checkout' is performed.
+The 'update' procedures supported both from the command line as well as
 through the `submodule.<name>.update` configuration are:
 
 	checkout;; the commit recorded in the superproject will be
@@ -150,8 +150,8 @@ checked out in the submodule.
 	merge;; the commit recorded in the superproject will be merged
 	    into the current branch in the submodule.
 
-The following procedures are only available via the `submodule.<name>.update`
-configuration variable:
+The following 'update' procedures are only available via the
+`submodule.<name>.update` configuration variable:
 
 	custom command;; arbitrary shell command that takes a single
 	    argument (the sha1 of the commit recorded in the

-- 
2.16.0.rc0.223.g4a4ac8367
Stefan Beller· Jan 8, 2018, 19:08 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 0/8] Doc/submodules: a few updates

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 7 quoted lines
> These are just a few improvements that I thought would make the documentation
> related to submodules a little better in various way such as readability,
> consistency etc., These were things I noticed while reading thise documents.
>
> Sorry, for the highly granular patches. I did the commits as and when I was
> reading them and tried to keep them focused to one particular change by rebasing
> them as needed. In case they need some change, let me know.

While small patches are really appreciated for code (bisect, automated testing, and the general difficulty to reason about code, as a very small change may affect the whole code base), I am not sure if they benefit in documentation. Documentation is a rather local human readable thing, so by changing one sentence we don't affect the understanding of documentation at a completely unrelated place.

Also it helps to read more than just sentence fragments, i.e. I tried looking at the whole paragraph for review. May I suggest to squash them all and resend as one patch?

>
> I based these patches on top of 'master'.

I am not aware of other submodule patches affecting documentation in master..pu, so this should be easy to merge.

Show 18 quoted lines
>
> Apart from the changes, I saw a few things that needed improvement/clarification
> but wasn't able to do that myself due to my limited knowledge of submodules. They
> are listed below. I'll add in patches for them if they are correctly clarified.
>
>
> 1.
>
>  man gitsubmodules
>
>        ·   The configuration file $GIT_DIR/config in the superproject. Typical configuration at this place is controlling if a submodule is
>            recursed into at all via the active flag for example.
>
>            If the submodule is not yet initialized, then the configuration inside the submodule does not exist yet, so configuration where to
>            obtain the submodule from is configured here for example.
>
> What's the "active flag" mentioned above? Also I find the phrase "is recursed into at all"
> to be a little slippery. How could it be improved?

There are multiple ways to indicate if a submodule is "active", i.e. if Git is supposed to pay attention. Historically we had to set the submodule.<name>.url flag in the config, but last year Brandon added submodule.active as well as submodule.<name>.active which supersede the .url flag.

(See is_submodule_active() in submodule.c to see the definitive answer to "should Git pay attention?") https://github.com/git/git/blob/master/submodule.c#L224

I wonder if this indicates a lack of documentation when the active flags were introduced. They are found in 'man git config', but maybe we need to spell them out explicitly in the submodule related docs.

Show 17 quoted lines
> 2.
>
>  man git submodule
>
>        update
>            ...
>
>            checkout
>                ....
>
>                If --force is specified, the submodule will be checked out (using git checkout --force if appropriate), even if the commit
>                specified in the index of the containing repository already matches the commit checked out in the submodule.
>
> I'm not sure this is conveying all the information it should be conveying.
> It seems to making the user wonder, "How at all does 'git submodule update --force'
> differs from 'git submodule update'?" also "using git checkout --force if appropriate"
> seems to be invoking all sorts confusion as "appropriate" is superfluous.

When "submodule update" is invoked with the `--force` flag, that flag is passed on to the 'checkout' operation. If you do not give the --force, then the checkout will also be done without --force.

>
> How could these confusions be clarified?
I tried giving an alternative snippet above, not sure how else to tell.
Kaartic Sivaraam· Jan 9, 2018, 17:06 UTC · re: Stefan Beller · lore

Re: [PATCH 0/8] Doc/submodules: a few updates

On Tuesday 09 January 2018 12:38 AM, Stefan Beller wrote:
Show 18 quoted lines
> On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> wrote:
> 
> While small patches are really appreciated for code (bisect, automated
> testing, and
> the general difficulty to reason about code, as a very small change
> may affect the whole
> code base), I am not sure if they benefit in documentation.
> Documentation is a rather
> local human readable thing, so by changing one sentence we don't
> affect the understanding
> of documentation at a completely unrelated place.
> 
> Also it helps to read more than just sentence fragments, i.e. I tried
> looking at the
> whole paragraph for review. May I suggest to squash them all and
> resend as one patch?
>

I wouldn't mind that. I thought it might be easy to find to find the parts I changed when the patches are small. So, I sent them without squashing them together. In case you feel it's not worth, let me know so I'll squash them in.

BTW, in case I did squash them in, would it be nice to keep the commit subjects of the current patch series as bullet points in the unified commit message?

Show 36 quoted lines
> 
>>
>> I based these patches on top of 'master'.
> 
> I am not aware of other submodule patches affecting documentation in master..pu,
> so this should be easy to merge.
> 
>>
>> Apart from the changes, I saw a few things that needed improvement/clarification
>> but wasn't able to do that myself due to my limited knowledge of submodules. They
>> are listed below. I'll add in patches for them if they are correctly clarified.
>>
>>
>> 1.
>>
>>  man gitsubmodules
>>
>>        ·   The configuration file $GIT_DIR/config in the superproject. Typical configuration at this place is controlling if a submodule is
>>            recursed into at all via the active flag for example.
>>
>>            If the submodule is not yet initialized, then the configuration inside the submodule does not exist yet, so configuration where to
>>            obtain the submodule from is configured here for example.
>>
>> What's the "active flag" mentioned above? Also I find the phrase "is recursed into at all"
>> to be a little slippery. How could it be improved?
> 
> There are multiple ways to indicate if a submodule is "active", i.e. if Git is
> supposed to pay attentio. Historically we had to set the
> submodule.<name>.url flag in the config, but last year Brandon added
> submodule.active as well as submodule.<name>.active which supersede
> the .url flag.
> 
> (See is_submodule_active() in submodule.c to see the definitive answer to
> "should Git pay attention?")
> https://github.com/git/git/blob/master/submodule.c#L224
> 
Thanks for the info!
Show 6 quoted lines
> I wonder if this indicates a lack of documentation when the active
> flags were introduced.
> They are found in 'man git config', but maybe we need to spell them
> out explicitly
> in the submodule related docs.
>

Possibly. So, why not in Documentation/gitsubmodules! Here's a replaced version of that paragraph,

    * The configuration file `$GIT_DIR/config` in the superproject.
   Typically this file is used to specify whether the submodule
   is recursed into at all via the `active` flag for example. A
   submodule is considered active if `submodule.<name>.url` is set
   or if the submodules path is present in `submodule.active` or
   if `submodule.<name>.url` is set.
Show 23 quoted lines
>> 2.
>>
>>  man git submodule
>>
>>        update
>>            ...
>>
>>            checkout
>>                ....
>>
>>                If --force is specified, the submodule will be checked out (using git checkout --force if appropriate), even if the commit
>>                specified in the index of the containing repository already matches the commit checked out in the submodule.
>>
>> I'm not sure this is conveying all the information it should be conveying.
>> It seems to making the user wonder, "How at all does 'git submodule update --force'
>> differs from 'git submodule update'?" also "using git checkout --force if appropriate"
>> seems to be invoking all sorts confusion as "appropriate" is superfluous.
> 
> When "submodule update" is invoked with the `--force` flag, that flag is passed
> on to the 'checkout' operation. If you do not give the --force, then
> the checkout
> will also be done without --force.
>

If that's the case then shouldn't the "if appropriate" part of "(using git checkout --force if appropriate)" be dropped? That seems to make it clear, at least for me. Or is intended as '--force' will not be passed to git checkout all the time?

Show 5 quoted lines
>>
>> How could these confusions be clarified?
> 
> I tried giving an alternative snippet above, not sure how else to tell.
> 
-- 
Kaartic

Quote: "Be creative. Be adventurous. Be original. And above all else, be
young." - Wonder Woman
Stefan Beller· Jan 9, 2018, 18:50 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH 0/8] Doc/submodules: a few updates

On Tue, Jan 9, 2018 at 9:06 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 28 quoted lines
> On Tuesday 09 January 2018 12:38 AM, Stefan Beller wrote:
>> On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
>> <kaartic.sivaraam@gmail.com> wrote:
>>
>> While small patches are really appreciated for code (bisect, automated
>> testing, and
>> the general difficulty to reason about code, as a very small change
>> may affect the whole
>> code base), I am not sure if they benefit in documentation.
>> Documentation is a rather
>> local human readable thing, so by changing one sentence we don't
>> affect the understanding
>> of documentation at a completely unrelated place.
>>
>> Also it helps to read more than just sentence fragments, i.e. I tried
>> looking at the
>> whole paragraph for review. May I suggest to squash them all and
>> resend as one patch?
>>
>
> I wouldn't mind that. I thought it might be easy to find to find the
> parts I changed when the patches are small. So, I sent them without
> squashing them together. In case you feel it's not worth, let me know so
> I'll squash them in.
>
> BTW, in case I did squash them in, would it be nice to keep the commit
> subjects of the current patch series as bullet points in the unified
> commit message?
Sure.
Show 16 quoted lines
>> I wonder if this indicates a lack of documentation when the active
>> flags were introduced.
>> They are found in 'man git config', but maybe we need to spell them
>> out explicitly
>> in the submodule related docs.
>>
>
> Possibly. So, why not in Documentation/gitsubmodules! Here's a replaced
> version of that paragraph,
>
>     * The configuration file `$GIT_DIR/config` in the superproject.
>    Typically this file is used to specify whether the submodule
>    is recursed into at all via the `active` flag for example. A
>    submodule is considered active if `submodule.<name>.url` is set
>    or if the submodules path is present in `submodule.active` or
>    if `submodule.<name>.url` is set.

I wonder if we'd want to give an example later, and first describe the mechanics precisely:

   The configuration file `$GIT_DIR/config` in the superproject.
    Git only recurses into active submodules. A submodule is
    considered active (a) if `submodule.<name>.active` is set
    or (b) if the submodules path is matches the pathsepc in
    `submodule.active` or (c) if `submodule.<name>.url` is set.
    (c) is a historical artefact and will be ignored if the pathspec
    set in (b) excludes the submodule. For example:
    [submodule "foo"]
        active = false
        url = https://example.org/foo
    [submodule "bar"]
        active = true
        url = https://example.org/bar
    [submodule "baz"]
        url = https://example.org/baz
    In the above config only the submodule bar and baz are active,
    bar due to (a) and baz due to (c). Another example
    [submodule "foo"]
        active = true
        url = https://example.org/foo
    [submodule "bar"]
        url = https://example.org/bar
    [submodule "baz"]
        url = https://example.org/baz
    [submodule "bob"]
        ignore = true
    [submodule]
        active = b*
        active = (:exclude) baz
    In here all submodules except baz (foo, bar, bob) are active.
    'foo' due to its own active flag and all the others due to the
    submodule active pathspec, which specifies that any submodule
    starting with 'b' except 'baz' are also active, no matter if the .url field
    is present.
Show 29 quoted lines
>>> 2.
>>>
>>>  man git submodule
>>>
>>>        update
>>>            ...
>>>
>>>            checkout
>>>                ....
>>>
>>>                If --force is specified, the submodule will be checked out (using git checkout --force if appropriate), even if the commit
>>>                specified in the index of the containing repository already matches the commit checked out in the submodule.
>>>
>>> I'm not sure this is conveying all the information it should be conveying.
>>> It seems to making the user wonder, "How at all does 'git submodule update --force'
>>> differs from 'git submodule update'?" also "using git checkout --force if appropriate"
>>> seems to be invoking all sorts confusion as "appropriate" is superfluous.
>>
>> When "submodule update" is invoked with the `--force` flag, that flag is passed
>> on to the 'checkout' operation. If you do not give the --force, then
>> the checkout
>> will also be done without --force.
>>
>
> If that's the case then shouldn't the "if appropriate" part of "(using
> git checkout --force if appropriate)" be dropped? That seems to make it
> clear, at least for me. Or is intended as '--force' will not be passed
> to git checkout all the time?
>

Yes, essentially we only pass the force flag when we were given the force flag ("when appropriate" :) Not sure how to say that otherwise. But dropping sounds good)

Stefan
Kaartic Sivaraam· Jan 10, 2018, 06:49 UTC · re: Kaartic Sivaraam · lore

[PATCH v2 0/2] Doc/submodules: a few updates

Quoting from v1,
    These are just a few improvements that I thought would make the documentation
    related to submodules a little better in various way such as readability,
    consistency etc., These were things I noticed while reading thise documents.
Change since v2: 
 I've squashed the fine grained patches into 2 patches that touch two distinct
 documents. This v2 conatins a lot of changes suggested for v1 and few that I
 caught by myself since v1.
This patch is based on 'master' just like v1.
Inter-word-diff v1..v2:
Show changes to 2 files +4 −0

Documentation/git-submodule.txt, Documentation/gitsubmodules.txt

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 5c4d941cc..801d291ca 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -140,7 +140,7 @@ through the `submodule.<name>.update` configuration are:
	    checked out in the submodule on a detached HEAD.
+
If `--force` is specified, the submodule will be checked out (using
`git checkout [---force` if appropriate),-]{+--force`),+} even if the commit specified
in the index of the containing repository already matches the commit
checked out in the submodule.

diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index 339fb73db..ce2369c2d 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -36,7 +36,7 @@ The `gitlink` entry contains the object name of the commit that the
superproject expects the submodule’s working directory to be at.

The section `submodule.foo.*` in the `.gitmodules` file gives additional
hints to [-Gits-]{+Git's+} porcelain layer. For example, the `submodule.foo.url`
setting specifies where to obtain the submodule.

Submodules can be used for at least two different use cases:
@@ -51,21 +51,21 @@ Submodules can be used for at least two different use cases:

2. Splitting a (logically single) project into multiple
   repositories and tying them back together. This can be used to
   overcome current limitations of [-Gits-]{+Git's+} implementation to have
   finer grained access:

    * Size of the [-git-]{+Git+} repository:
      In its current form Git scales up poorly for large repositories containing
      content that is not compressed by delta computation between trees.
      [-Therefore-]{+For example,+} you can use submodules to hold large binary assets
      and these repositories [-are then-]{+can be+} shallowly cloned such that you do not
      have a large history locally.
    * Transfer size:
      In its current form Git requires the whole working tree present. It
      does not allow partial trees to be transferred in fetch or clone.
      If [-you have your-]{+the+} project [-as-]{+you work on consists of+} multiple repositories tied
      together as submodules in a superproject, you can avoid fetching the
      working trees of the repositories you are not interested in.
    * Access control:
      By restricting user access to submodules, this can be used to implement
      read/write policies for different users.
@@ -76,10 +76,10 @@ The configuration of submodules
Submodule operations can be configured using the following mechanisms
(from highest to lowest precedence):

 * The command line [-arguments of-]{+for+} those commands that support taking [-submodule-]
[-   specifications.-]{+submodules+}
{+   as part of their pathspecs.+} Most commands have a boolean flag
   [-'--recurse-submodules'-]{+`--recurse-submodules`+} which specify whether [-they should-]{+to+} recurse into submodules.
   Examples are [-`ls-files` or-]{+`grep` and+} `checkout`.
   Some commands take enums, such as `fetch` and `push`, where you can
   specify how submodules are affected.

@@ -101,17 +101,17 @@ remotes are configured in the submodule as usual in the `$GIT_DIR/config`
file.

 * The configuration file `$GIT_DIR/config` in the superproject.
   [-Typical configuration at this place is controlling if a submodule-]
[-   is recursed-]{+Git only recurses+} into [-at all via the `active` flag for example.-]{+active submodules (see 'ACTIVE SUBMODULES'+}
{+   section below).+}
+
If the submodule is not yet initialized, then the configuration
inside the submodule does not exist yet, so[-configuration-] where to
obtain the submodule from is configured here for example.

 * The `.gitmodules` file inside the superproject. [-Additionally, if mapping-]
[-   is required between a submodule's name and its path, a-]{+A+} project usually
   uses this file to suggest defaults for the upstream collection
   of [-repositories.-]{+repositories for the mapping that is required between a+}
{+   submodule's name and its path.+}
+
This file mainly serves as the mapping between the name and path of submodules
in the superproject, such that the submodule's Git directory can be
@@ -141,8 +141,8 @@ directory is automatically moved to `$GIT_DIR/modules/<name>/`
of the superproject.

 * Deinitialized submodule: A `gitlink`, and a `.gitmodules` entry,
but no submodule working directory. The submodule’s [-git-]{+Git+} directory
may be there as after deinitializing the [-git-]{+Git+} directory is kept around.
The directory which is supposed to be the working directory is empty instead.
+
A submodule can be deinitialized by running `git submodule deinit`.
@@ -164,6 +164,53 @@ from another repository.
To completely remove a submodule, manually delete
`$GIT_DIR/modules/<name>/`.

{+Active submodules+}
{+-----------------+}

{+A submodule is considered active,+}

{+  (a) if `submodule.<name>.active` is set+}
{+     or+}
{+  (b) if the submodules path matches the pathspec in `submodule.active`+}
{+     or+}
{+  (c) if `submodule.<name>.url` is set.+}

{+For example:+}

{+    [submodule "foo"]+}
{+        active = false+}
{+        url = https://example.org/foo+}
{+    [submodule "bar"]+}
{+        active = true+}
{+        url = https://example.org/bar+}
{+    [submodule "baz"]+}
{+        url = https://example.org/baz+}

{+In the above config only the submodule bar and baz are active,+}
{+bar due to (a) and baz due to (c).+}

{+Note that '(c)' is a historical artefact and will be ignored if the+}
{+pathspec set in (b) excludes the submodule. For example:+}

{+    [submodule "foo"]+}
{+        active = true+}
{+        url = https://example.org/foo+}
{+    [submodule "bar"]+}
{+        url = https://example.org/bar+}
{+    [submodule "baz"]+}
{+        url = https://example.org/baz+}
{+    [submodule "bob"]+}
{+        ignore = true+}
{+    [submodule]+}
{+        active = b*+}
{+        active = (:exclude) baz+}

{+In here all submodules except baz (foo, bar, bob) are active.+}
{+'foo' due to its own active flag and all the others due to the+}
{+submodule active pathspec, which specifies that any submodule+}
{+starting with 'b' except 'baz' are also active, no matter if+}
{+the .url field is present.+}

Workflow for a third party library
----------------------------------



Kaartic Sivaraam (2):
  Doc/gitsubmodules: make some changes to improve readability and syntax
  Doc/git-submodule: improve readability and grammar of a sentence

 Documentation/git-submodule.txt | 12 +++---
 Documentation/gitsubmodules.txt | 93 +++++++++++++++++++++++++++++++----------
 2 files changed, 78 insertions(+), 27 deletions(-)

-- 
2.16.0.rc0.223.g4a4ac8367
Kaartic Sivaraam· Jan 10, 2018, 06:49 UTC · re: Kaartic Sivaraam · lore

[PATCH v2 1/2] Doc/gitsubmodules: make some changes to improve readability and syntax

* Only mention porcelain commands in examples
* Split a sentence for better readability
* Add missing apostrophes
* Clearly specify the advantages of using submodules
* Avoid abbreviations
* Use "Git" consistently
* Improve readability of certain lines
* Clarify when a submodule is considered active
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/gitsubmodules.txt | 93 +++++++++++++++++++++++++++++++----------
 1 file changed, 72 insertions(+), 21 deletions(-)
Show changes to Documentation/gitsubmodules.txt +72 −21
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index 46cf120f6..ce2369c2d 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -36,8 +36,8 @@ The `gitlink` entry contains the object name of the commit that the
 superproject expects the submodule’s working directory to be at.
 
 The section `submodule.foo.*` in the `.gitmodules` file gives additional
-hints to Gits porcelain layer such as where to obtain the submodule via
-the `submodule.foo.url` setting.
+hints to Git's porcelain layer. For example, the `submodule.foo.url`
+setting specifies where to obtain the submodule.
 
 Submodules can be used for at least two different use cases:
 
@@ -51,18 +51,21 @@ Submodules can be used for at least two different use cases:
 
 2. Splitting a (logically single) project into multiple
    repositories and tying them back together. This can be used to
-   overcome current limitations of Gits implementation to have
+   overcome current limitations of Git's implementation to have
    finer grained access:
 
-    * Size of the git repository:
+    * Size of the Git repository:
       In its current form Git scales up poorly for large repositories containing
       content that is not compressed by delta computation between trees.
-      However you can also use submodules to e.g. hold large binary assets
-      and these repositories are then shallowly cloned such that you do not
+      For example, you can use submodules to hold large binary assets
+      and these repositories can be shallowly cloned such that you do not
       have a large history locally.
     * Transfer size:
       In its current form Git requires the whole working tree present. It
       does not allow partial trees to be transferred in fetch or clone.
+      If the project you work on consists of multiple repositories tied
+      together as submodules in a superproject, you can avoid fetching the
+      working trees of the repositories you are not interested in.
     * Access control:
       By restricting user access to submodules, this can be used to implement
       read/write policies for different users.
@@ -73,9 +76,10 @@ The configuration of submodules
 Submodule operations can be configured using the following mechanisms
 (from highest to lowest precedence):
 
- * The command line for those commands that support taking submodule specs.
-   Most commands have a boolean flag '--recurse-submodules' whether to
-   recurse into submodules. Examples are `ls-files` or `checkout`.
+ * The command line for those commands that support taking submodules
+   as part of their pathspecs. Most commands have a boolean flag
+   `--recurse-submodules` which specify whether to recurse into submodules.
+   Examples are `grep` and `checkout`.
    Some commands take enums, such as `fetch` and `push`, where you can
    specify how submodules are affected.
 
@@ -87,8 +91,8 @@ Submodule operations can be configured using the following mechanisms
 For example an effect from the submodule's `.gitignore` file
 would be observed when you run `git status --ignore-submodules=none` in
 the superproject. This collects information from the submodule's working
-directory by running `status` in the submodule, which does pay attention
-to its `.gitignore` file.
+directory by running `status` in the submodule while paying attention
+to the `.gitignore` file of the submodule.
 +
 The submodule's `$GIT_DIR/config` file would come into play when running
 `git push --recurse-submodules=check` in the superproject, as this would
@@ -97,20 +101,20 @@ remotes are configured in the submodule as usual in the `$GIT_DIR/config`
 file.
 
  * The configuration file `$GIT_DIR/config` in the superproject.
-   Typical configuration at this place is controlling if a submodule
-   is recursed into at all via the `active` flag for example.
+   Git only recurses into active submodules (see 'ACTIVE SUBMODULES'
+   section below).
 +
 If the submodule is not yet initialized, then the configuration
-inside the submodule does not exist yet, so configuration where to
+inside the submodule does not exist yet, so where to
 obtain the submodule from is configured here for example.
 
- * the `.gitmodules` file inside the superproject. Additionally to the
-   required mapping between submodule's name and path, a project usually
+ * The `.gitmodules` file inside the superproject. A project usually
    uses this file to suggest defaults for the upstream collection
-   of repositories.
+   of repositories for the mapping that is required between a
+   submodule's name and its path.
 +
-This file mainly serves as the mapping between name and path in
-the superproject, such that the submodule's git directory can be
+This file mainly serves as the mapping between the name and path of submodules
+in the superproject, such that the submodule's Git directory can be
 located.
 +
 If the submodule has never been initialized, this is the only place
@@ -137,8 +141,8 @@ directory is automatically moved to `$GIT_DIR/modules/<name>/`
 of the superproject.
 
  * Deinitialized submodule: A `gitlink`, and a `.gitmodules` entry,
-but no submodule working directory. The submodule’s git directory
-may be there as after deinitializing the git directory is kept around.
+but no submodule working directory. The submodule’s Git directory
+may be there as after deinitializing the Git directory is kept around.
 The directory which is supposed to be the working directory is empty instead.
 +
 A submodule can be deinitialized by running `git submodule deinit`.
@@ -160,6 +164,53 @@ from another repository.
 To completely remove a submodule, manually delete
 `$GIT_DIR/modules/<name>/`.
 
+Active submodules
+-----------------
+
+A submodule is considered active,
+
+  (a) if `submodule.<name>.active` is set
+     or
+  (b) if the submodules path matches the pathspec in `submodule.active`
+     or
+  (c) if `submodule.<name>.url` is set.
+
+For example:
+
+    [submodule "foo"]
+        active = false
+        url = https://example.org/foo
+    [submodule "bar"]
+        active = true
+        url = https://example.org/bar
+    [submodule "baz"]
+        url = https://example.org/baz
+
+In the above config only the submodule bar and baz are active,
+bar due to (a) and baz due to (c).
+
+Note that '(c)' is a historical artefact and will be ignored if the
+pathspec set in (b) excludes the submodule. For example:
+
+    [submodule "foo"]
+        active = true
+        url = https://example.org/foo
+    [submodule "bar"]
+        url = https://example.org/bar
+    [submodule "baz"]
+        url = https://example.org/baz
+    [submodule "bob"]
+        ignore = true
+    [submodule]
+        active = b*
+        active = (:exclude) baz
+
+In here all submodules except baz (foo, bar, bob) are active.
+'foo' due to its own active flag and all the others due to the
+submodule active pathspec, which specifies that any submodule
+starting with 'b' except 'baz' are also active, no matter if
+the .url field is present.
+
 Workflow for a third party library
 ----------------------------------
 

-- 
2.16.0.rc0.223.g4a4ac8367
Stefan Beller· Jan 10, 2018, 20:49 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH v2 1/2] Doc/gitsubmodules: make some changes to improve readability and syntax

On Tue, Jan 9, 2018 at 10:49 PM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 20 quoted lines
> * Only mention porcelain commands in examples
>
> * Split a sentence for better readability
>
> * Add missing apostrophes
>
> * Clearly specify the advantages of using submodules
>
> * Avoid abbreviations
>
> * Use "Git" consistently
>
> * Improve readability of certain lines
>
> * Clarify when a submodule is considered active
>
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Helped-by: Stefan Beller <sbeller@google.com>
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---

Thanks for sending it in one patch, Stefan

Show 77 quoted lines
>  Documentation/gitsubmodules.txt | 93 +++++++++++++++++++++++++++++++----------
>  1 file changed, 72 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> index 46cf120f6..ce2369c2d 100644
> --- a/Documentation/gitsubmodules.txt
> +++ b/Documentation/gitsubmodules.txt
> @@ -36,8 +36,8 @@ The `gitlink` entry contains the object name of the commit that the
>  superproject expects the submodule’s working directory to be at.
>
>  The section `submodule.foo.*` in the `.gitmodules` file gives additional
> -hints to Gits porcelain layer such as where to obtain the submodule via
> -the `submodule.foo.url` setting.
> +hints to Git's porcelain layer. For example, the `submodule.foo.url`
> +setting specifies where to obtain the submodule.
>
>  Submodules can be used for at least two different use cases:
>
> @@ -51,18 +51,21 @@ Submodules can be used for at least two different use cases:
>
>  2. Splitting a (logically single) project into multiple
>     repositories and tying them back together. This can be used to
> -   overcome current limitations of Gits implementation to have
> +   overcome current limitations of Git's implementation to have
>     finer grained access:
>
> -    * Size of the git repository:
> +    * Size of the Git repository:
>        In its current form Git scales up poorly for large repositories containing
>        content that is not compressed by delta computation between trees.
> -      However you can also use submodules to e.g. hold large binary assets
> -      and these repositories are then shallowly cloned such that you do not
> +      For example, you can use submodules to hold large binary assets
> +      and these repositories can be shallowly cloned such that you do not
>        have a large history locally.
>      * Transfer size:
>        In its current form Git requires the whole working tree present. It
>        does not allow partial trees to be transferred in fetch or clone.
> +      If the project you work on consists of multiple repositories tied
> +      together as submodules in a superproject, you can avoid fetching the
> +      working trees of the repositories you are not interested in.
>      * Access control:
>        By restricting user access to submodules, this can be used to implement
>        read/write policies for different users.
> @@ -73,9 +76,10 @@ The configuration of submodules
>  Submodule operations can be configured using the following mechanisms
>  (from highest to lowest precedence):
>
> - * The command line for those commands that support taking submodule specs.
> -   Most commands have a boolean flag '--recurse-submodules' whether to
> -   recurse into submodules. Examples are `ls-files` or `checkout`.
> + * The command line for those commands that support taking submodules
> +   as part of their pathspecs. Most commands have a boolean flag
> +   `--recurse-submodules` which specify whether to recurse into submodules.
> +   Examples are `grep` and `checkout`.
>     Some commands take enums, such as `fetch` and `push`, where you can
>     specify how submodules are affected.
>
> @@ -87,8 +91,8 @@ Submodule operations can be configured using the following mechanisms
>  For example an effect from the submodule's `.gitignore` file
>  would be observed when you run `git status --ignore-submodules=none` in
>  the superproject. This collects information from the submodule's working
> -directory by running `status` in the submodule, which does pay attention
> -to its `.gitignore` file.
> +directory by running `status` in the submodule while paying attention
> +to the `.gitignore` file of the submodule.
>  +
>  The submodule's `$GIT_DIR/config` file would come into play when running
>  `git push --recurse-submodules=check` in the superproject, as this would
> @@ -97,20 +101,20 @@ remotes are configured in the submodule as usual in the `$GIT_DIR/config`
>  file.
>
>   * The configuration file `$GIT_DIR/config` in the superproject.
> -   Typical configuration at this place is controlling if a submodule
> -   is recursed into at all via the `active` flag for example.
> +   Git only recurses into active submodules (see 'ACTIVE SUBMODULES'
> +   section below).
The section below is capitalized differently?
Show 35 quoted lines
>  +
>  If the submodule is not yet initialized, then the configuration
> -inside the submodule does not exist yet, so configuration where to
> +inside the submodule does not exist yet, so where to
>  obtain the submodule from is configured here for example.
>
> - * the `.gitmodules` file inside the superproject. Additionally to the
> -   required mapping between submodule's name and path, a project usually
> + * The `.gitmodules` file inside the superproject. A project usually
>     uses this file to suggest defaults for the upstream collection
> -   of repositories.
> +   of repositories for the mapping that is required between a
> +   submodule's name and its path.
>  +
> -This file mainly serves as the mapping between name and path in
> -the superproject, such that the submodule's git directory can be
> +This file mainly serves as the mapping between the name and path of submodules
> +in the superproject, such that the submodule's Git directory can be
>  located.
>  +
>  If the submodule has never been initialized, this is the only place
> @@ -137,8 +141,8 @@ directory is automatically moved to `$GIT_DIR/modules/<name>/`
>  of the superproject.
>
>   * Deinitialized submodule: A `gitlink`, and a `.gitmodules` entry,
> -but no submodule working directory. The submodule’s git directory
> -may be there as after deinitializing the git directory is kept around.
> +but no submodule working directory. The submodule’s Git directory
> +may be there as after deinitializing the Git directory is kept around.
>  The directory which is supposed to be the working directory is empty instead.
>  +
>  A submodule can be deinitialized by running `git submodule deinit`.
> @@ -160,6 +164,53 @@ from another repository.
>  To completely remove a submodule, manually delete
>  `$GIT_DIR/modules/<name>/`.
> +Active submodules

The examples were not meant to be taken literally into the patch. ;) (I should have been more careful for that :P)

Show 9 quoted lines
> +-----------------
> +
> +A submodule is considered active,
> +
> +  (a) if `submodule.<name>.active` is set
> +     or
> +  (b) if the submodules path matches the pathspec in `submodule.active`
> +     or
> +  (c) if `submodule.<name>.url` is set.

and these are evaluated in this order, so if (a) or (b) is set but indicates that the submodule is not active, we're done evaluating. as seen by the example, if we have an .active = false set, the url doesn't matter whether it is present or not.

Show 14 quoted lines
> +
> +For example:
> +
> +    [submodule "foo"]
> +        active = false
> +        url = https://example.org/foo
> +    [submodule "bar"]
> +        active = true
> +        url = https://example.org/bar
> +    [submodule "baz"]
> +        url = https://example.org/baz
> +
> +In the above config only the submodule bar and baz are active,
> +bar due to (a) and baz due to (c).
"foo" is inactive because (a) takes precedence over (c).
Show 16 quoted lines
> +
> +Note that '(c)' is a historical artefact and will be ignored if the
> +pathspec set in (b) excludes the submodule. For example:
> +
> +    [submodule "foo"]
> +        active = true
> +        url = https://example.org/foo
> +    [submodule "bar"]
> +        url = https://example.org/bar
> +    [submodule "baz"]
> +        url = https://example.org/baz
> +    [submodule "bob"]
> +        ignore = true
> +    [submodule]
> +        active = b*
> +        active = (:exclude) baz
 :(exclude)baz
This is regular pathspec magic, see 'pathspec' in 'man gitglossary'
Show 12 quoted lines
> +In here all submodules except baz (foo, bar, bob) are active.
> +'foo' due to its own active flag and all the others due to the
> +submodule active pathspec, which specifies that any submodule
> +starting with 'b' except 'baz' are also active, no matter if
> +the .url field is present.
> +
>  Workflow for a third party library
>  ----------------------------------
>
> --
> 2.16.0.rc0.223.g4a4ac8367
>
Kaartic Sivaraam· Jan 10, 2018, 06:49 UTC · re: Kaartic Sivaraam · lore

[PATCH v2 2/2] Doc/git-submodule: improve readability and grammar of a sentence

While at it, correctly quote important words.
Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/git-submodule.txt | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
Show changes to Documentation/git-submodule.txt +6 −6
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index ff612001d..801d291ca 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -132,15 +132,15 @@ expects by cloning missing submodules and updating the working tree of
 the submodules. The "updating" can be done in several ways depending
 on command line options and the value of `submodule.<name>.update`
 configuration variable. The command line option takes precedence over
-the configuration variable. if neither is given, a checkout is performed.
-update procedures supported both from the command line as well as setting
-`submodule.<name>.update`:
+the configuration variable. If neither is given, a 'checkout' is performed.
+The 'update' procedures supported both from the command line as well as
+through the `submodule.<name>.update` configuration are:
 
 	checkout;; the commit recorded in the superproject will be
 	    checked out in the submodule on a detached HEAD.
 +
 If `--force` is specified, the submodule will be checked out (using
-`git checkout --force` if appropriate), even if the commit specified
+`git checkout --force`), even if the commit specified
 in the index of the containing repository already matches the commit
 checked out in the submodule.
 
@@ -150,8 +150,8 @@ checked out in the submodule.
 	merge;; the commit recorded in the superproject will be merged
 	    into the current branch in the submodule.
 
-The following procedures are only available via the `submodule.<name>.update`
-configuration variable:
+The following 'update' procedures are only available via the
+`submodule.<name>.update` configuration variable:
 
 	custom command;; arbitrary shell command that takes a single
 	    argument (the sha1 of the commit recorded in the

-- 
2.16.0.rc0.223.g4a4ac8367
Kaartic Sivaraam· Jan 14, 2018, 17:37 UTC · re: Kaartic Sivaraam · lore

[PATCH v3 0/2] Doc/submodules: a few updates

Quoting from v1,
    These are just a few improvements that I thought would make the documentation
    related to submodules a little better in various way such as readability,
    consistency etc., These were things I noticed while reading thise documents.
Changes since v2:
   - Made some changes suggested by Stefan.
   - A few more that caught my eyes.
Inter diff between v2 and v3:
Show changes to 2 files +40 −33

Documentation/git-submodule.txt, Documentation/gitsubmodules.txt

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 801d291ca..71c5618e8 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -70,8 +70,8 @@ status [--cached] [--recursive] [--] [<path>...]::
 	Show the status of the submodules. This will print the SHA-1 of the
 	currently checked out commit for each submodule, along with the
 	submodule path and the output of 'git describe' for the
-	SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not
-	initialized, `+` if the currently checked out submodule commit
+	SHA-1. Each SHA-1 will possibly be prefixed with `-` if the submodule is
+	not initialized, `+` if the currently checked out submodule commit
 	does not match the SHA-1 found in the index of the containing
 	repository and `U` if the submodule has merge conflicts.
 +
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index ce2369c2d..47bbc62e8 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -101,7 +101,7 @@ remotes are configured in the submodule as usual in the `$GIT_DIR/config`
 file.
 
  * The configuration file `$GIT_DIR/config` in the superproject.
-   Git only recurses into active submodules (see 'ACTIVE SUBMODULES'
+   Git only recurses into active submodules (see "ACTIVE SUBMODULES"
    section below).
 +
 If the submodule is not yet initialized, then the configuration
@@ -164,52 +164,59 @@ from another repository.
 To completely remove a submodule, manually delete
 `$GIT_DIR/modules/<name>/`.
 
-Active submodules
+ACTIVE SUBMODULES
 -----------------
 
 A submodule is considered active,
 
-  (a) if `submodule.<name>.active` is set
+  (a) if `submodule.<name>.active` is set to `true`
      or
-  (b) if the submodules path matches the pathspec in `submodule.active`
+  (b) if the submodule's path matches the pathspec in `submodule.active`
      or
   (c) if `submodule.<name>.url` is set.
 
+and these are evaluated in this order.
+
 For example:
 
-    [submodule "foo"]
-        active = false
-        url = https://example.org/foo
-    [submodule "bar"]
-        active = true
-        url = https://example.org/bar
-    [submodule "baz"]
-        url = https://example.org/baz
+  [submodule "foo"]
+    active = false
+    url = https://example.org/foo
+  [submodule "bar"]
+    active = true
+    url = https://example.org/bar
+  [submodule "baz"]
+    url = https://example.org/baz
 
-In the above config only the submodule bar and baz are active,
-bar due to (a) and baz due to (c).
+In the above config only the submodule 'bar' and 'baz' are active,
+'bar' due to (a) and 'baz' due to (c). 'foo' is inactive because
+(a) takes precedence over (c).
 
-Note that '(c)' is a historical artefact and will be ignored if the
-pathspec set in (b) excludes the submodule. For example:
+Note that (c) is a historical artefact and will be ignored if the
+(a) and (b) specify that the submodule is not active. In other words,
+if we have an `submodule.<name>.active` set to `false` or if the
+submodule's path is excluded in the pathspec in `submodule.active`, the
+url doesn't matter whether it is present or not. This is illustrated in
+the example that follows.
 
-    [submodule "foo"]
-        active = true
-        url = https://example.org/foo
-    [submodule "bar"]
-        url = https://example.org/bar
-    [submodule "baz"]
-        url = https://example.org/baz
-    [submodule "bob"]
-        ignore = true
-    [submodule]
-        active = b*
-        active = (:exclude) baz
+  [submodule "foo"]
+    active = true
+    url = https://example.org/foo
+  [submodule "bar"]
+    url = https://example.org/bar
+  [submodule "baz"]
+    url = https://example.org/baz
+  [submodule "bob"]
+    ignore = true
+  [submodule]
+    active = b*
+    active = :(exclude) baz
 
-In here all submodules except baz (foo, bar, bob) are active.
+In here all submodules except 'baz' (foo, bar, bob) are active.
 'foo' due to its own active flag and all the others due to the
 submodule active pathspec, which specifies that any submodule
-starting with 'b' except 'baz' are also active, no matter if
-the .url field is present.
+starting with 'b' except 'baz' are also active, regardless of the
+presence of the .url field.
 
 Workflow for a third party library
 ----------------------------------



Kaartic Sivaraam (2):
  Doc/gitsubmodules: make some changes to improve readability and syntax
  Doc/git-submodule: improve readability and grammar of a sentence

 Documentation/git-submodule.txt |  16 +++----
 Documentation/gitsubmodules.txt | 100 +++++++++++++++++++++++++++++++---------
 2 files changed, 87 insertions(+), 29 deletions(-)

-- 
2.16.0.rc1.281.g969645f98
Kaartic Sivaraam· Jan 14, 2018, 17:37 UTC · re: Kaartic Sivaraam · lore

[PATCH v3 1/2] Doc/gitsubmodules: make some changes to improve readability and syntax

* Only mention porcelain commands in examples
* Split a sentence for better readability
* Add missing apostrophes
* Clearly specify the advantages of using submodules
* Avoid abbreviations
* Use "Git" consistently
* Improve readability of certain lines
* Clarify when a submodule is considered active
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/gitsubmodules.txt | 100 +++++++++++++++++++++++++++++++---------
 1 file changed, 79 insertions(+), 21 deletions(-)
Show changes to Documentation/gitsubmodules.txt +79 −21
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index 46cf120f6..4d6c17782 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -36,8 +36,8 @@ The `gitlink` entry contains the object name of the commit that the
 superproject expects the submodule’s working directory to be at.
 
 The section `submodule.foo.*` in the `.gitmodules` file gives additional
-hints to Gits porcelain layer such as where to obtain the submodule via
-the `submodule.foo.url` setting.
+hints to Git's porcelain layer. For example, the `submodule.foo.url`
+setting specifies where to obtain the submodule.
 
 Submodules can be used for at least two different use cases:
 
@@ -51,18 +51,21 @@ Submodules can be used for at least two different use cases:
 
 2. Splitting a (logically single) project into multiple
    repositories and tying them back together. This can be used to
-   overcome current limitations of Gits implementation to have
+   overcome current limitations of Git's implementation to have
    finer grained access:
 
-    * Size of the git repository:
+    * Size of the Git repository:
       In its current form Git scales up poorly for large repositories containing
       content that is not compressed by delta computation between trees.
-      However you can also use submodules to e.g. hold large binary assets
-      and these repositories are then shallowly cloned such that you do not
+      For example, you can use submodules to hold large binary assets
+      and these repositories can be shallowly cloned such that you do not
       have a large history locally.
     * Transfer size:
       In its current form Git requires the whole working tree present. It
       does not allow partial trees to be transferred in fetch or clone.
+      If the project you work on consists of multiple repositories tied
+      together as submodules in a superproject, you can avoid fetching the
+      working trees of the repositories you are not interested in.
     * Access control:
       By restricting user access to submodules, this can be used to implement
       read/write policies for different users.
@@ -73,9 +76,10 @@ The configuration of submodules
 Submodule operations can be configured using the following mechanisms
 (from highest to lowest precedence):
 
- * The command line for those commands that support taking submodule specs.
-   Most commands have a boolean flag '--recurse-submodules' whether to
-   recurse into submodules. Examples are `ls-files` or `checkout`.
+ * The command line for those commands that support taking submodules
+   as part of their pathspecs. Most commands have a boolean flag
+   `--recurse-submodules` which specify whether to recurse into submodules.
+   Examples are `grep` and `checkout`.
    Some commands take enums, such as `fetch` and `push`, where you can
    specify how submodules are affected.
 
@@ -87,8 +91,8 @@ Submodule operations can be configured using the following mechanisms
 For example an effect from the submodule's `.gitignore` file
 would be observed when you run `git status --ignore-submodules=none` in
 the superproject. This collects information from the submodule's working
-directory by running `status` in the submodule, which does pay attention
-to its `.gitignore` file.
+directory by running `status` in the submodule while paying attention
+to the `.gitignore` file of the submodule.
 +
 The submodule's `$GIT_DIR/config` file would come into play when running
 `git push --recurse-submodules=check` in the superproject, as this would
@@ -97,20 +101,20 @@ remotes are configured in the submodule as usual in the `$GIT_DIR/config`
 file.
 
  * The configuration file `$GIT_DIR/config` in the superproject.
-   Typical configuration at this place is controlling if a submodule
-   is recursed into at all via the `active` flag for example.
+   Git only recurses into active submodules (see "ACTIVE SUBMODULES"
+   section below).
 +
 If the submodule is not yet initialized, then the configuration
-inside the submodule does not exist yet, so configuration where to
+inside the submodule does not exist yet, so where to
 obtain the submodule from is configured here for example.
 
- * the `.gitmodules` file inside the superproject. Additionally to the
-   required mapping between submodule's name and path, a project usually
+ * The `.gitmodules` file inside the superproject. A project usually
    uses this file to suggest defaults for the upstream collection
-   of repositories.
+   of repositories for the mapping that is required between a
+   submodule's name and its path.
 +
-This file mainly serves as the mapping between name and path in
-the superproject, such that the submodule's git directory can be
+This file mainly serves as the mapping between the name and path of submodules
+in the superproject, such that the submodule's Git directory can be
 located.
 +
 If the submodule has never been initialized, this is the only place
@@ -137,8 +141,8 @@ directory is automatically moved to `$GIT_DIR/modules/<name>/`
 of the superproject.
 
  * Deinitialized submodule: A `gitlink`, and a `.gitmodules` entry,
-but no submodule working directory. The submodule’s git directory
-may be there as after deinitializing the git directory is kept around.
+but no submodule working directory. The submodule’s Git directory
+may be there as after deinitializing the Git directory is kept around.
 The directory which is supposed to be the working directory is empty instead.
 +
 A submodule can be deinitialized by running `git submodule deinit`.
@@ -160,6 +164,60 @@ from another repository.
 To completely remove a submodule, manually delete
 `$GIT_DIR/modules/<name>/`.
 
+ACTIVE SUBMODULES
+-----------------
+
+A submodule is considered active,
+
+  (a) if `submodule.<name>.active` is set to `true`
+     or
+  (b) if the submodule's path matches the pathspec in `submodule.active`
+     or
+  (c) if `submodule.<name>.url` is set.
+
+and these are evaluated in this order.
+
+For example:
+
+  [submodule "foo"]
+    active = false
+    url = https://example.org/foo
+  [submodule "bar"]
+    active = true
+    url = https://example.org/bar
+  [submodule "baz"]
+    url = https://example.org/baz
+
+In the above config only the submodule 'bar' and 'baz' are active,
+'bar' due to (a) and 'baz' due to (c). 'foo' is inactive because
+(a) takes precedence over (c)
+
+Note that (c) is a historical artefact and will be ignored if the
+(a) and (b) specify that the submodule is not active. In other words,
+if we have an `submodule.<name>.active` set to `false` or if the
+submodule's path is excluded in the pathspec in `submodule.active`, the
+url doesn't matter whether it is present or not. This is illustrated in
+the example that follows.
+
+  [submodule "foo"]
+    active = true
+    url = https://example.org/foo
+  [submodule "bar"]
+    url = https://example.org/bar
+  [submodule "baz"]
+    url = https://example.org/baz
+  [submodule "bob"]
+    ignore = true
+  [submodule]
+    active = b*
+    active = :(exclude) baz
+
+In here all submodules except 'baz' (foo, bar, bob) are active.
+'foo' due to its own active flag and all the others due to the
+submodule active pathspec, which specifies that any submodule
+starting with 'b' except 'baz' are also active, regardless of the
+presence of the .url field.
+
 Workflow for a third party library
 ----------------------------------
 

-- 
2.16.0.rc1.281.g969645f98
Stefan Beller· Jan 16, 2018, 20:03 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH v3 1/2] Doc/gitsubmodules: make some changes to improve readability and syntax

On Sun, Jan 14, 2018 at 9:37 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 20 quoted lines
> * Only mention porcelain commands in examples
>
> * Split a sentence for better readability
>
> * Add missing apostrophes
>
> * Clearly specify the advantages of using submodules
>
> * Avoid abbreviations
>
> * Use "Git" consistently
>
> * Improve readability of certain lines
>
> * Clarify when a submodule is considered active
>
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Helped-by: Stefan Beller <sbeller@google.com>
> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---

Thanks, Stefan

Show 173 quoted lines
>  Documentation/gitsubmodules.txt | 100 +++++++++++++++++++++++++++++++---------
>  1 file changed, 79 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> index 46cf120f6..4d6c17782 100644
> --- a/Documentation/gitsubmodules.txt
> +++ b/Documentation/gitsubmodules.txt
> @@ -36,8 +36,8 @@ The `gitlink` entry contains the object name of the commit that the
>  superproject expects the submodule’s working directory to be at.
>
>  The section `submodule.foo.*` in the `.gitmodules` file gives additional
> -hints to Gits porcelain layer such as where to obtain the submodule via
> -the `submodule.foo.url` setting.
> +hints to Git's porcelain layer. For example, the `submodule.foo.url`
> +setting specifies where to obtain the submodule.
>
>  Submodules can be used for at least two different use cases:
>
> @@ -51,18 +51,21 @@ Submodules can be used for at least two different use cases:
>
>  2. Splitting a (logically single) project into multiple
>     repositories and tying them back together. This can be used to
> -   overcome current limitations of Gits implementation to have
> +   overcome current limitations of Git's implementation to have
>     finer grained access:
>
> -    * Size of the git repository:
> +    * Size of the Git repository:
>        In its current form Git scales up poorly for large repositories containing
>        content that is not compressed by delta computation between trees.
> -      However you can also use submodules to e.g. hold large binary assets
> -      and these repositories are then shallowly cloned such that you do not
> +      For example, you can use submodules to hold large binary assets
> +      and these repositories can be shallowly cloned such that you do not
>        have a large history locally.
>      * Transfer size:
>        In its current form Git requires the whole working tree present. It
>        does not allow partial trees to be transferred in fetch or clone.
> +      If the project you work on consists of multiple repositories tied
> +      together as submodules in a superproject, you can avoid fetching the
> +      working trees of the repositories you are not interested in.
>      * Access control:
>        By restricting user access to submodules, this can be used to implement
>        read/write policies for different users.
> @@ -73,9 +76,10 @@ The configuration of submodules
>  Submodule operations can be configured using the following mechanisms
>  (from highest to lowest precedence):
>
> - * The command line for those commands that support taking submodule specs.
> -   Most commands have a boolean flag '--recurse-submodules' whether to
> -   recurse into submodules. Examples are `ls-files` or `checkout`.
> + * The command line for those commands that support taking submodules
> +   as part of their pathspecs. Most commands have a boolean flag
> +   `--recurse-submodules` which specify whether to recurse into submodules.
> +   Examples are `grep` and `checkout`.
>     Some commands take enums, such as `fetch` and `push`, where you can
>     specify how submodules are affected.
>
> @@ -87,8 +91,8 @@ Submodule operations can be configured using the following mechanisms
>  For example an effect from the submodule's `.gitignore` file
>  would be observed when you run `git status --ignore-submodules=none` in
>  the superproject. This collects information from the submodule's working
> -directory by running `status` in the submodule, which does pay attention
> -to its `.gitignore` file.
> +directory by running `status` in the submodule while paying attention
> +to the `.gitignore` file of the submodule.
>  +
>  The submodule's `$GIT_DIR/config` file would come into play when running
>  `git push --recurse-submodules=check` in the superproject, as this would
> @@ -97,20 +101,20 @@ remotes are configured in the submodule as usual in the `$GIT_DIR/config`
>  file.
>
>   * The configuration file `$GIT_DIR/config` in the superproject.
> -   Typical configuration at this place is controlling if a submodule
> -   is recursed into at all via the `active` flag for example.
> +   Git only recurses into active submodules (see "ACTIVE SUBMODULES"
> +   section below).
>  +
>  If the submodule is not yet initialized, then the configuration
> -inside the submodule does not exist yet, so configuration where to
> +inside the submodule does not exist yet, so where to
>  obtain the submodule from is configured here for example.
>
> - * the `.gitmodules` file inside the superproject. Additionally to the
> -   required mapping between submodule's name and path, a project usually
> + * The `.gitmodules` file inside the superproject. A project usually
>     uses this file to suggest defaults for the upstream collection
> -   of repositories.
> +   of repositories for the mapping that is required between a
> +   submodule's name and its path.
>  +
> -This file mainly serves as the mapping between name and path in
> -the superproject, such that the submodule's git directory can be
> +This file mainly serves as the mapping between the name and path of submodules
> +in the superproject, such that the submodule's Git directory can be
>  located.
>  +
>  If the submodule has never been initialized, this is the only place
> @@ -137,8 +141,8 @@ directory is automatically moved to `$GIT_DIR/modules/<name>/`
>  of the superproject.
>
>   * Deinitialized submodule: A `gitlink`, and a `.gitmodules` entry,
> -but no submodule working directory. The submodule’s git directory
> -may be there as after deinitializing the git directory is kept around.
> +but no submodule working directory. The submodule’s Git directory
> +may be there as after deinitializing the Git directory is kept around.
>  The directory which is supposed to be the working directory is empty instead.
>  +
>  A submodule can be deinitialized by running `git submodule deinit`.
> @@ -160,6 +164,60 @@ from another repository.
>  To completely remove a submodule, manually delete
>  `$GIT_DIR/modules/<name>/`.
>
> +ACTIVE SUBMODULES
> +-----------------
> +
> +A submodule is considered active,
> +
> +  (a) if `submodule.<name>.active` is set to `true`
> +     or
> +  (b) if the submodule's path matches the pathspec in `submodule.active`
> +     or
> +  (c) if `submodule.<name>.url` is set.
> +
> +and these are evaluated in this order.
> +
> +For example:
> +
> +  [submodule "foo"]
> +    active = false
> +    url = https://example.org/foo
> +  [submodule "bar"]
> +    active = true
> +    url = https://example.org/bar
> +  [submodule "baz"]
> +    url = https://example.org/baz
> +
> +In the above config only the submodule 'bar' and 'baz' are active,
> +'bar' due to (a) and 'baz' due to (c). 'foo' is inactive because
> +(a) takes precedence over (c)
> +
> +Note that (c) is a historical artefact and will be ignored if the
> +(a) and (b) specify that the submodule is not active. In other words,
> +if we have an `submodule.<name>.active` set to `false` or if the
> +submodule's path is excluded in the pathspec in `submodule.active`, the
> +url doesn't matter whether it is present or not. This is illustrated in
> +the example that follows.
> +
> +  [submodule "foo"]
> +    active = true
> +    url = https://example.org/foo
> +  [submodule "bar"]
> +    url = https://example.org/bar
> +  [submodule "baz"]
> +    url = https://example.org/baz
> +  [submodule "bob"]
> +    ignore = true
> +  [submodule]
> +    active = b*
> +    active = :(exclude) baz
> +
> +In here all submodules except 'baz' (foo, bar, bob) are active.
> +'foo' due to its own active flag and all the others due to the
> +submodule active pathspec, which specifies that any submodule
> +starting with 'b' except 'baz' are also active, regardless of the
> +presence of the .url field.
> +
>  Workflow for a third party library
>  ----------------------------------
>
> --
> 2.16.0.rc1.281.g969645f98
>
Kaartic Sivaraam· Jan 14, 2018, 17:37 UTC · re: Kaartic Sivaraam · lore

[PATCH v3 2/2] Doc/git-submodule: improve readability and grammar of a sentence

While at it, correctly quote important words.
Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/git-submodule.txt | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
Show changes to Documentation/git-submodule.txt +8 −8
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index ff612001d..71c5618e8 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -70,8 +70,8 @@ status [--cached] [--recursive] [--] [<path>...]::
 	Show the status of the submodules. This will print the SHA-1 of the
 	currently checked out commit for each submodule, along with the
 	submodule path and the output of 'git describe' for the
-	SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not
-	initialized, `+` if the currently checked out submodule commit
+	SHA-1. Each SHA-1 will possibly be prefixed with `-` if the submodule is
+	not initialized, `+` if the currently checked out submodule commit
 	does not match the SHA-1 found in the index of the containing
 	repository and `U` if the submodule has merge conflicts.
 +
@@ -132,15 +132,15 @@ expects by cloning missing submodules and updating the working tree of
 the submodules. The "updating" can be done in several ways depending
 on command line options and the value of `submodule.<name>.update`
 configuration variable. The command line option takes precedence over
-the configuration variable. if neither is given, a checkout is performed.
-update procedures supported both from the command line as well as setting
-`submodule.<name>.update`:
+the configuration variable. If neither is given, a 'checkout' is performed.
+The 'update' procedures supported both from the command line as well as
+through the `submodule.<name>.update` configuration are:
 
 	checkout;; the commit recorded in the superproject will be
 	    checked out in the submodule on a detached HEAD.
 +
 If `--force` is specified, the submodule will be checked out (using
-`git checkout --force` if appropriate), even if the commit specified
+`git checkout --force`), even if the commit specified
 in the index of the containing repository already matches the commit
 checked out in the submodule.
 
@@ -150,8 +150,8 @@ checked out in the submodule.
 	merge;; the commit recorded in the superproject will be merged
 	    into the current branch in the submodule.
 
-The following procedures are only available via the `submodule.<name>.update`
-configuration variable:
+The following 'update' procedures are only available via the
+`submodule.<name>.update` configuration variable:
 
 	custom command;; arbitrary shell command that takes a single
 	    argument (the sha1 of the commit recorded in the

-- 
2.16.0.rc1.281.g969645f98
Junio C Hamano· Jan 16, 2018, 20:02 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH v3 0/2] Doc/submodules: a few updates

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:
>     These are just a few improvements that I thought would make the documentation
>     related to submodules a little better in various way such as readability,
>     consistency etc., These were things I noticed while reading thise documents.

Overall they look like reasonable improvements. I had a few "Huh?" moments while reading the resulting text, but nothing show-stopping.

Kaartic Sivaraam· Jan 17, 2018, 02:45 UTC · re: Junio C Hamano · lore

Re: [PATCH v3 0/2] Doc/submodules: a few updates

On Wednesday 17 January 2018 01:32 AM, Junio C Hamano wrote:
> I had a few "Huh?"
> moments while reading the resulting text, but nothing show-stopping.
>

It always happens when there are people around who are trying to be over careful :)

Anyways, it's only now that I remember that I've missed a change that I thought of doing. The change is about clarifying what a "de-initialized" submodule means and what an "inactive" submodule means and how they work together (IIUC, a submodule has not active flag when its deinitialized). I foresee people confusing 'init' and 'active'. So, I thought the documentation should be helpful enough in that aspect. Documenation/gitsubmodules doesn't seem to be talking much about 'init'. (It talks about 'active' a lot after these patches :)

Now I think it's better to do that as separate change and move this forward as I don't want to make this clumsy anymore. Please let me know, if I'm over thinking things again. :)

-- 
Kaartic

← back to recent threads