| Message ID | 1113893dd36a1e8cf72331dd01f36206b44f45ad.1580116685.git.bert.wesarg@googlemail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | doc: clarify "explicitly given" in push.default | expand |
On Mon, Jan 27, 2020 at 10:25:03AM +0100, Bert Wesarg wrote: > The documentation for push.default mentions that it is used if no > refspec is "explicitly given". Let's clarify that giving a refspec on > the command-line _or_ in the config will override it. Yep, looks good to me. > Signed-off-by: Jeff King <peff@peff.net> > Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> I don't know that we need my S-o-b anymore. The content in this one is all you. :) (But certainly I don't mind endorsing it). -Peff
Bert Wesarg <bert.wesarg@googlemail.com> writes: > The documentation for push.default mentions that it is used if no > refspec is "explicitly given". Let's clarify that giving a refspec on > the command-line _or_ in the config will override it. > > Signed-off-by: Jeff King <peff@peff.net> > Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> > --- > Documentation/config/push.txt | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > Cc: peff@peff.net > > diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt > index 0a0e000569..d560362c9a 100644 > --- a/Documentation/config/push.txt > +++ b/Documentation/config/push.txt > @@ -1,9 +1,11 @@ > push.default:: > Defines the action `git push` should take if no refspec is > - explicitly given. Different values are well-suited for > - specific workflows; for instance, in a purely central workflow > - (i.e. the fetch source is equal to the push destination), > - `upstream` is probably what you want. Possible values are: > + neither explicitly (on the command-line) nor implicitly (via a > + `remote.*.push` config option) given. Different values are > + well-suited for specific workflows; for instance, in a purely > + central workflow (i.e. the fetch source is equal to the push > + destination), `upstream` is probably what you want. Possible > + values are: > + > -- Hmph, I am not sure the act of deliberately setting remote.*.push configuration should not count as an explicit request to Git the user makes. Immediately follows the above, the description of one of the possible values read thusly: * `nothing` - do not push anything (error out) unless a refspec is explicitly given. This is primarily meant for people who want to avoid mistakes by always being explicit. which may need an adjustment to keep the whole coherent. If we decide to say that setting configuration does not count as explicit, then "unless a refspec is explicitly given" should be updated to match. There may be other mention of "explicitly" that needs to be adjusted (I didn't hunt for it, but the above one was adjacent and I couldn't not see it). If we have to change anything in the description, I would say that we can just drop "explicitly". There are ways to give refspec from the command line, remote.*.push configuration, in .git/remotes file, etc. If it were "if you give refspec from command line, X happens, but giving a config-sourced refspec does not cause X to happen", that may be a good reason to invent and use a new phrase "implicitly given" that is not used in this paragraph. But push.default kicks in only when *none* of these ways is used to give *any* refspec, so there is not much point differenciating between the command line sourced refspec and config sourced refspec in the context of discussing this feature, I would think.
On Tue, Jan 28, 2020 at 02:11:01PM -0800, Junio C Hamano wrote: > > push.default:: > > Defines the action `git push` should take if no refspec is > > - explicitly given. Different values are well-suited for > > - specific workflows; for instance, in a purely central workflow > > - (i.e. the fetch source is equal to the push destination), > > - `upstream` is probably what you want. Possible values are: > > + neither explicitly (on the command-line) nor implicitly (via a > > + `remote.*.push` config option) given. Different values are > > + well-suited for specific workflows; for instance, in a purely > > + central workflow (i.e. the fetch source is equal to the push > > + destination), `upstream` is probably what you want. Possible > > + values are: > > + > > -- > > Hmph, I am not sure the act of deliberately setting remote.*.push > configuration should not count as an explicit request to Git the > user makes. > > Immediately follows the above, the description of one of the > possible values read thusly: > > * `nothing` - do not push anything (error out) unless a refspec is > explicitly given. This is primarily meant for people who want to > avoid mistakes by always being explicit. > > which may need an adjustment to keep the whole coherent. Yeah, you're right. The term "explicit" gets thrown around a fair bit there. In that sense my original was slightly better, in that it defines "explicit" (one might say it even does so...explicitly). But... > If we have to change anything in the description, I would say that > we can just drop "explicitly". [...] Yes, I like dropping that word even better. Though I'd still slightly worry that somebody might not consider configured refspecs. Saying more clearly "any refspec no matter where it comes from" might still be worthwhile. I.e., something like: Defines the action `git push` should take if no refspec is given (whether from the command-line, config, or elsewhere). ? -Peff
Jeff King <peff@peff.net> writes: > Though I'd still slightly worry that somebody might not consider > configured refspecs. Saying more clearly "any refspec no matter where it > comes from" might still be worthwhile. I.e., something like: > > Defines the action `git push` should take if no refspec is given > (whether from the command-line, config, or elsewhere). That's 100x better than to say "explicit" "implicit" etc. and then have readers guess what the adjectives mean or explain what they mean in (parentheses).
On Tue, Jan 28, 2020 at 09:21:32PM -0800, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > Though I'd still slightly worry that somebody might not consider > > configured refspecs. Saying more clearly "any refspec no matter where it > > comes from" might still be worthwhile. I.e., something like: > > > > Defines the action `git push` should take if no refspec is given > > (whether from the command-line, config, or elsewhere). > > That's 100x better than to say "explicit" "implicit" etc. and then > have readers guess what the adjectives mean or explain what they > mean in (parentheses). OK, here it is in patch form, then, so we can (hopefully) wrap this up. -- >8 -- Subject: [PATCH] doc: drop "explicitly given" from push.default description The documentation for push.default mentions that it is used if no refspec is "explicitly given". Let's drop the notion of "explicit" here, since it's vague, and just mention that any refspec from anywhere is sufficient to override this. I've dropped the mention of "explicitly given" frmo the definition of the "nothing" value right below, too. It's close enough to our clarification that it should be obvious we mean the same type of "given" here. Signed-off-by: Jeff King <peff@peff.net> --- Note that there's one other use of the word "explicit" in the context, but it is used appropriately. :) Documentation/config/push.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt index 0a0e000569..54871f8213 100644 --- a/Documentation/config/push.txt +++ b/Documentation/config/push.txt @@ -1,14 +1,15 @@ push.default:: Defines the action `git push` should take if no refspec is - explicitly given. Different values are well-suited for + given (whether from the command-line, config, or elsewhere). + Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), `upstream` is probably what you want. Possible values are: + -- * `nothing` - do not push anything (error out) unless a refspec is - explicitly given. This is primarily meant for people who want to + given. This is primarily meant for people who want to avoid mistakes by always being explicit. * `current` - push the current branch to update a branch with the same
diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt index 0a0e000569..d560362c9a 100644 --- a/Documentation/config/push.txt +++ b/Documentation/config/push.txt @@ -1,9 +1,11 @@ push.default:: Defines the action `git push` should take if no refspec is - explicitly given. Different values are well-suited for - specific workflows; for instance, in a purely central workflow - (i.e. the fetch source is equal to the push destination), - `upstream` is probably what you want. Possible values are: + neither explicitly (on the command-line) nor implicitly (via a + `remote.*.push` config option) given. Different values are + well-suited for specific workflows; for instance, in a purely + central workflow (i.e. the fetch source is equal to the push + destination), `upstream` is probably what you want. Possible + values are: + --