Re: [PATCH 0/8] Doc/submodules: a few updates
- From
Stefan Beller <sbeller@google.com>
- Date
- Jan 8, 2018, 19:08 UTC
- Message-ID
- <CAGZ79kZ-UNCyCzmg=5PQ_p5xbmCp7HUc0=TXNBxwTjZDCnJtBg@mail.gmail.com>
- In-Reply-To
- <20180106184614.20115-1-kaartic.sivaraam@gmail.com>
On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
Show 7 quoted lines
> These are just a few improvements that I thought would make the documentation > related to submodules a little better in various way such as readability, > consistency etc., These were things I noticed while reading thise documents. > > Sorry, for the highly granular patches. I did the commits as and when I was > reading them and tried to keep them focused to one particular change by rebasing > them as needed. In case they need some change, let me know.
While small patches are really appreciated for code (bisect, automated testing, and the general difficulty to reason about code, as a very small change may affect the whole code base), I am not sure if they benefit in documentation. Documentation is a rather local human readable thing, so by changing one sentence we don't affect the understanding of documentation at a completely unrelated place.
Also it helps to read more than just sentence fragments, i.e. I tried looking at the whole paragraph for review. May I suggest to squash them all and resend as one patch?
> > I based these patches on top of 'master'.
I am not aware of other submodule patches affecting documentation in master..pu, so this should be easy to merge.
Show 18 quoted lines
> > Apart from the changes, I saw a few things that needed improvement/clarification > but wasn't able to do that myself due to my limited knowledge of submodules. They > are listed below. I'll add in patches for them if they are correctly clarified. > > > 1. > > man gitsubmodules > > · The configuration file $GIT_DIR/config in the superproject. Typical configuration at this place is controlling if a submodule is > recursed into at all via the active flag for example. > > If the submodule is not yet initialized, then the configuration inside the submodule does not exist yet, so configuration where to > obtain the submodule from is configured here for example. > > What's the "active flag" mentioned above? Also I find the phrase "is recursed into at all" > to be a little slippery. How could it be improved?
There are multiple ways to indicate if a submodule is "active", i.e. if Git is supposed to pay attention. Historically we had to set the submodule.<name>.url flag in the config, but last year Brandon added submodule.active as well as submodule.<name>.active which supersede the .url flag.
(See is_submodule_active() in submodule.c to see the definitive answer to "should Git pay attention?") https://github.com/git/git/blob/master/submodule.c#L224
I wonder if this indicates a lack of documentation when the active flags were introduced. They are found in 'man git config', but maybe we need to spell them out explicitly in the submodule related docs.
Show 17 quoted lines
> 2. > > man git submodule > > update > ... > > checkout > .... > > If --force is specified, the submodule will be checked out (using git checkout --force if appropriate), even if the commit > specified in the index of the containing repository already matches the commit checked out in the submodule. > > I'm not sure this is conveying all the information it should be conveying. > It seems to making the user wonder, "How at all does 'git submodule update --force' > differs from 'git submodule update'?" also "using git checkout --force if appropriate" > seems to be invoking all sorts confusion as "appropriate" is superfluous.
When "submodule update" is invoked with the `--force` flag, that flag is passed on to the 'checkout' operation. If you do not give the --force, then the checkout will also be done without --force.
> > How could these confusions be clarified?
I tried giving an alternative snippet above, not sure how else to tell.