On Tuesday 09 January 2018 12:38 AM, Stefan Beller wrote: > On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam > <kaartic.sivaraam@xxxxxxxxx> 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:
signature.asc
Description: OpenPGP digital signature
