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

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

[Kaartic Sivaraam]

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

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

[Kaartic Sivaraam]

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/gitsubmodules.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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

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

[Eric Sunshine]

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.

However, since you're touching this, you could apply the s/Gits/Git's/ fix.

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

[Stefan Beller]

On Sat, Jan 6, 2018 at 4:29 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> 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.

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

[Kaartic Sivaraam]

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
       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

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

[Stefan Beller]

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> 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.


>        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
>

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

[Kaartic Sivaraam]

[-- Attachment #1.1: Type: text/plain, Size: 743 bytes --]

>>        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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Kaartic Sivaraam]

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.
     * 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

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

[Eric Sunshine]

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
> @@ -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..."

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

[Stefan Beller]

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> 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?

>      * 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
>

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

[Kaartic Sivaraam]

[-- Attachment #1.1: Type: text/plain, Size: 1110 bytes --]

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?

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Stefan Beller]

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.

> 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)

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

[Kaartic Sivaraam]

[-- Attachment #1.1: Type: text/plain, Size: 2678 bytes --]

On Wednesday 10 January 2018 12:31 AM, Stefan Beller wrote:
> 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.


>> 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!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Kaartic Sivaraam]

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

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

[Eric Sunshine]

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
> @@ -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".

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

[Stefan Beller]

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> 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?

> -   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
>

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

[Kaartic Sivaraam]

[-- Attachment #1.1: Type: text/plain, Size: 1150 bytes --]

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?


>> -   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
>>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Stefan Beller]

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.

Stefan

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

[Kaartic Sivaraam]

[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]

On Wednesday 10 January 2018 12:56 AM, Stefan Beller wrote:
> 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 :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Kaartic Sivaraam]

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 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

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

[Eric Sunshine]

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.

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

[Stefan Beller]

On Sat, Jan 6, 2018 at 4:39 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> 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!

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

[Kaartic Sivaraam]

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.
 +
 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

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

[Eric Sunshine]

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
> @@ -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.

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

[Stefan Beller]

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> 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?

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

>     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

>  +
>  If the submodule has never been initialized, this is the only place
> --
> 2.16.0.rc0.223.g4a4ac8367
>

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

[Kaartic Sivaraam]

[-- Attachment #1.1: Type: text/plain, Size: 3293 bytes --]

On Tuesday 09 January 2018 12:19 AM, Stefan Beller wrote:
> 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) ;)


>>  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?

  * 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Stefan Beller]

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

>   * 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

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

[Kaartic Sivaraam]

[-- Attachment #1.1: Type: text/plain, Size: 2719 bytes --]

On Wednesday 10 January 2018 01:01 AM, Stefan Beller wrote:
>>>>  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.


>>
>>>> - * 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Kaartic Sivaraam]

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:
 
 	checkout;; the commit recorded in the superproject will be
 	    checked out in the submodule on a detached HEAD.
-- 
2.16.0.rc0.223.g4a4ac8367

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

[Stefan Beller]

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> 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

>
>         checkout;; the commit recorded in the superproject will be
>             checked out in the submodule on a detached HEAD.
> --
> 2.16.0.rc0.223.g4a4ac8367
>

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

[Kaartic Sivaraam]

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 Documentation/git-submodule.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

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

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

[Stefan Beller]

On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> 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.

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

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

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

[Kaartic Sivaraam]

[-- Attachment #1.1: Type: text/plain, Size: 4930 bytes --]

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?


> 
>>
>> 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!


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


>> 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?

>>
>> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Stefan Beller]

On Tue, Jan 9, 2018 at 9:06 AM, Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> 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.

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

>>> 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

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

[Kaartic Sivaraam]

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:

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

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

[Kaartic Sivaraam]

* 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(-)

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

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

[Stefan Beller]

On Tue, Jan 9, 2018 at 10:49 PM, Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> * 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

>  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?


>  +
>  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)

> +-----------------
> +
> +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.

> +
> +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
> +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'

> +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
>

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

[Kaartic Sivaraam]

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(-)

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

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

[Kaartic Sivaraam]

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:

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

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

[Kaartic Sivaraam]

* 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(-)

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

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

[Stefan Beller]

On Sun, Jan 14, 2018 at 9:37 AM, Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> * 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

>  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
>

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

[Kaartic Sivaraam]

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(-)

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

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

[Junio C Hamano]

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.

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

[Kaartic Sivaraam]

[-- Attachment #1.1: Type: text/plain, Size: 999 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]