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

From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Date: Jan 9, 2018, 17:06 UTC
Message-ID: <64503247-66ad-03cf-26ba-3383337971b5@gmail.com>
In-Reply-To: <CAGZ79kZ-UNCyCzmg=5PQ_p5xbmCp7HUc0=TXNBxwTjZDCnJtBg@mail.gmail.com>

On Tuesday 09 January 2018 12:38 AM, Stefan Beller wrote:

Show 18 quoted lines

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

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

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

Show 36 quoted lines

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

Thanks for the info!

Show 6 quoted lines

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

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

    * The configuration file `$GIT_DIR/config` in the superproject.
   Typically this file is used to specify whether the submodule
   is recursed into at all via the `active` flag for example. A
   submodule is considered active if `submodule.<name>.url` is set
   or if the submodules path is present in `submodule.active` or
   if `submodule.<name>.url` is set.

Show 23 quoted lines

>> 2.
>>
>>  man git submodule
>>
>>        update
>>            ...
>>
>>            checkout
>>                ....
>>
>>                If --force is specified, the submodule will be checked out (using git checkout --force if appropriate), even if the commit
>>                specified in the index of the containing repository already matches the commit checked out in the submodule.
>>
>> I'm not sure this is conveying all the information it should be conveying.
>> It seems to making the user wonder, "How at all does 'git submodule update --force'
>> differs from 'git submodule update'?" also "using git checkout --force if appropriate"
>> seems to be invoking all sorts confusion as "appropriate" is superfluous.
> 
> When "submodule update" is invoked with the `--force` flag, that flag is passed
> on to the 'checkout' operation. If you do not give the --force, then
> the checkout
> will also be done without --force.
>

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

Show 5 quoted lines

>>
>> How could these confusions be clarified?
> 
> I tried giving an alternative snippet above, not sure how else to tell.
>

-- 
Kaartic

Quote: "Be creative. Be adventurous. Be original. And above all else, be
young." - Wonder Woman