All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: git@vger.kernel.org, Jens.Lehmann@web.de, peff@peff.net,
	phil.hord@gmail.com
Subject: Re: [PATCH 2/6] Teach remote.c about the remote.default configuration setting.
Date: Wed, 11 Jul 2012 15:04:06 -0700	[thread overview]
Message-ID: <7v8veqdkfd.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4FFDE4EB.3060100@xiplink.com> (Marc Branchaud's message of "Wed, 11 Jul 2012 16:41:15 -0400")

Marc Branchaud <marcnarc@xiplink.com> writes:

> On 12-07-11 02:21 PM, Junio C Hamano wrote:
>> marcnarc@xiplink.com writes:
>> 
>>> From: Marc Branchaud <marcnarc@xiplink.com>
>>>
>>> The code now has a default_remote_name and an effective_remote_name:
>>>
>>>  - default_remote_name is set by remote.default in the config, or is "origin"
>>>    if remote.default doesn't exist ("origin" was the fallback value before
>>>    this change).
>>>
>>>  - effective_remote_name is the name of the remote tracked by the current
>>>    branch, or is default_remote_name if the current branch doesn't have a
>>>    remote.
>>>
>>> This has a minor side effect on the default behavior of "git push"....
>> 
>> Hrm, is this a _minor_ side effect?
>
> Well, I thought so...  :)
>
> It's minor because of what you say:
>
>> Isn't that a natural and direct consequence of "now you can set
>> remote.default configuration to name the remote you want to use in
>> place of traditional 'origin'" feature?  I think changing the
>> behaviour of "git push" in such a way is the point (may not be the
>> only but one of the important points) of this series.
>
> I agree.  Phil Hord pointed out the change in behaviour and felt the commit
> message should explain it.
>
> Should I just remove "minor"?

Is it even a _side effect_?  Isn't this one of the primary points of
the series?  I do not think this patch makes sense if we did not
want that change to happen.

Or am I missing something?

>>> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
>>> index cb97cc1..fc17d39 100644
>>> --- a/Documentation/git-push.txt
>>> +++ b/Documentation/git-push.txt
>>> @@ -27,10 +27,16 @@ documentation for linkgit:git-receive-pack[1].
>>>  OPTIONS[[OPTIONS]]
>>>  ------------------
>>>  <repository>::
>>> -	The "remote" repository that is destination of a push
>>> +	The "remote" repository that is the destination of the push
>>>  	operation.  This parameter can be either a URL
>>>  	(see the section <<URLS,GIT URLS>> below) or the name
>>>  	of a remote (see the section <<REMOTES,REMOTES>> below).
>>> +	If this parameter is omitted, git tries to use the remote
>>> +	associated with the currently checked-out branch.  If there
>>> +	is no remote associated with the current branch, git uses
>>> +	the remote named by the "remote.default" configuration variable.
>>> +	If "remote.default" is not set, git uses the name "origin" even
>>> +	if there is no actual remote named "origin".
>> 
>> This comment applies to other changes to the documentation in this
>> patch I didn't quote, but I think the phrasing 'even if there is no
>> acutual remote named "origin"' needs to be rethought, because "we
>> use it even if there is no such remote determined with this logic"
>> applies equally to branch.$name.remote, remote.default or built-in
>> default value of remote.default which happens to be "origin".
>
> I'm sorry, but I'm having trouble understanding what you mean.  I don't see
> how the "because ..." part of your sentence suggests what aspect needs
> rephrasing.

You say the remote is taken from three places (branch.$name.remote,
remote.default, or 'origin').

Imagine there is remote.origin.url at all.  If remote.default is set
to 'origin', or branch.$name.remote for the current branch is set to
'origin', the repository you will try to use is 'origin'.  And you
will fail the same way if you try to push there.  It does not matter
if the hardcoded default gave you 'origin' or configuration variable
gave it to you.  The name is used regardless, even if there is no
actual remote under such name.

So "If 'remote.default' is not set, git uses the name "origin" even
if there is no actual remote", while is not untrue, is misleading.
Even if there is no actual remote 'origin', if 'remote.default' is
set to 'origin', git will use that name, and will fail the same way.

Just saying "If 'remote.default' is not set, git uses 'origin'" or
even "'remote.default', if unset, defaults to 'origin'" would be
sufficient.

  reply	other threads:[~2012-07-11 22:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-11 15:33 [PATCH v2 0/6] Default remote marcnarc
2012-07-11 15:33 ` [PATCH 1/6] Rename remote.c's default_remote_name static variables marcnarc
2012-07-11 15:33 ` [PATCH 2/6] Teach remote.c about the remote.default configuration setting marcnarc
2012-07-11 18:21   ` Junio C Hamano
2012-07-11 20:41     ` Marc Branchaud
2012-07-11 22:04       ` Junio C Hamano [this message]
2012-07-13 19:37         ` Marc Branchaud
2012-07-13 20:29           ` Junio C Hamano
2012-07-11 15:33 ` [PATCH 3/6] Teach "git remote" about remote.default marcnarc
2012-07-11 18:27   ` Junio C Hamano
2012-07-11 20:41     ` Marc Branchaud
2012-07-11 21:55       ` Junio C Hamano
2012-07-13 19:54         ` Marc Branchaud
2012-07-11 15:33 ` [PATCH 4/6] Teach clone to set remote.default marcnarc
2012-07-11 15:34 ` [PATCH 5/6] Test that plain "git fetch" uses remote.default when on a detached HEAD marcnarc
2012-07-11 15:34 ` [PATCH 6/6] Teach get_default_remote to respect remote.default marcnarc
2012-07-11 18:19 ` [PATCH v2 0/6] Default remote Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2012-07-05 22:11 [PATCH " marcnarc
2012-07-05 22:11 ` [PATCH 2/6] Teach remote.c about the remote.default configuration setting marcnarc
2012-07-05 22:50   ` Junio C Hamano
2012-07-06 14:36     ` Marc Branchaud
2012-07-06 19:31       ` Junio C Hamano
2012-07-06 19:57         ` Marc Branchaud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v8veqdkfd.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=marcnarc@xiplink.com \
    --cc=peff@peff.net \
    --cc=phil.hord@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.