Re: [PATCH 0/8] Doc/submodules: a few updates
- Date: Mon, 8 Jan 2018 11:08:42 -0800
- From: Stefan Beller <sbeller@xxxxxxxxxx>
- Subject: Re: [PATCH 0/8] Doc/submodules: a few updates
On Sat, Jan 6, 2018 at 10:46 AM, 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.
While small patches are really appreciated for code (bisect, automated
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.
> 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?")
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
in the submodule related docs.
> man git submodule
> 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
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.