Re: [PATCH 3/6] Teach "git remote" about remote.default.

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 11, 2012, 21:55 UTC
Message-ID: <7vd342dku3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4FFDE4ED.8020502@xiplink.com>

Marc Branchaud <marcnarc@xiplink.com> writes:

Show 8 quoted lines

> What about a warning displayed if "remote.default" is not set?  Something like:
>
> 	This repository does not have an explicitly configured default
> 	remote.  Selecting "origin" as the default remote repository.
> 	To suppress this warning, or if you wish to have a different
> 	default remote repository, run "git remote default <name>".
> 	In git X.Y, the default remote will be automatically configured
> 	as the first remote added to the repository.

When do you plan to issue the above message? Any time we default to 'origin' without remote.default?

I do not see a value to it---if the user has been happily using 'origin' as the default remote, there is no reason to give such a noise. We will keep defaulting to 'origin' even in the version of Git with this series in it.

A warning is necessary if we plan to _later_ add the "first remote created either by 'git clone' or 'git remote add' is automatically set as the value for remote.default configuration" feature, and the place to do so is "git clone" and "git remote add" that creates the first remote for the repository. If the name of the remote created by them is 'origin', then there is no need for warning, but if the user called that first remote with a name that is _not_ 'origin', later versions of Git will change the behaviour.

I can see a transition plan that goes like this:

Step 0.  With this series but without the "first one becomes default"

    $ git init
    $ git remote add upstream git://over.there.xz/git.git/
    hint: You may want to run "git remote default upstream" now so that
    hint: a lazy 'git push' and 'git fetch' defaults to this 'upstream'
    hint: repository, instead of 'origin' (which you do not yet have).

    $ git config --global advice.settingDefaultRemote false
    $ git remote rm upstream
    $ git remote add upstream git://over.there.xz/git.git/
    ... nothing, as the user declined the advice ...

Step 1.  "First one becomes default" as an opt-in feature

    $ git config --global --unset advice.settingDefaultRemote
    $ git init
    $ git remote add upstream git://over.there.xz/git.git/
    hint: You may want to run "git remote default upstream" now so that
    hint: a lazy 'git push' and 'git fetch' defaults to this 'upstream'
    hint: repository, instead of 'origin' (which you do not yet have).
    hint: "git config --global remote.firstRemoteBecomesDefault true" can be
    hint: used to make the first remote added to the repository the default
    hint: remote automatically.
    $ git remote default
    origin

    $ git config --global remote.firstRemoteBecomesDefault true
    $ git remote rm upstream
    $ git remote add upstream git://over.there.xz/git.git/
    ... nothing; user already knows about remote.firstRemoteBecomesDefault
    $ git remote default
    upstream

Step 2.  Start warning the default change for "First one becomes default"

    $ git config --global --unset advice.settingDefaultRemote
    $ git config --global --unset remote.firstRemoteBecomesDefault
    $ git init
    $ git remote add upstream git://over.there.xz/git.git/
    hint: You may want to run "git remote default upstream" now so that
    hint: a lazy 'git push' and 'git fetch' defaults to this 'upstream'
    hint: repository, instead of 'origin' (which you do not yet have).
    hint: "git config --global remote.firstRemoteBecomesDefault true" can be
    hint: used to make the first remote added to the repository the default
    hint: remote automatically.
    hint:
    hint: In future versions of Git, this will happen automatically.
    hint: If you do not want the first remote to become default, run
    hint: "git config --global remote.firstRemoteBecomesDefault false" now.

Step 3. "First one becomes default" is now default

    $ git config --global --unset advice.settingDefaultRemote
    $ git config --global --unset remote.firstRemoteBecomesDefault
    $ git init
    $ git remote add upstream git://over.there.xz/git.git/
    warning: Made 'upstream' the default remote for this repository.
    $ git remote default
    upstream

    $ git remote rm upstream
    $ git config --global remote.firstRemoteBecomesDefault true
    $ git init
    $ git remote add upstream git://over.there.xz/git.git/
    ... nothing; the user explicitly told us what to do
    $ git remote default
    upstream

    $ git remote rm upstream
    $ git config --global remote.firstRemoteBecomesDefault false
    $ git init
    $ git remote add upstream git://over.there.xz/git.git/
    ... nothing; the user explicitly told us what to do
    $ git remote default
    origin

> Since the "cmd_" prefix is already used for the main commands, perhaps
> another prefix for subcommands?  Maybe "sub_"?  Some of the shell-based
> commands use the main command itself as a prefix (e.g. bisect_start()).
> Doing that here would mean "remote_default()" etc.  Any preference?

No strong preference for file-scope-statics.

Show 23 quoted lines

>>> +{
>>> +	if (argc < 2)
>>> +		printf_ln("%s", remote_get_default_name());
>> 
>> Good.  If somebody anal cares about the vanilla hardcoded default
>> 'origin' and 'remote.default' having 'origin' as a configured value,
>> he should be using "git config" to ask the difference.  Users of
>> "remote default" interface should not have to care.
>> 
>>> +	else {
>>> +		const char *name = argv[1];
>>> +		if (remote_is_configured(name)) {
>>> +			git_config_set("remote.default", name);
>>> +			printf_ln(_("Default remote set to '%s'."), name);
>>> +		} else
>>> +			return error(_("No remote named '%s'."), name);
>>> +	}
>> 
>> I am not sure if this is a good idea.  Shouldn't "git remote default
>> frotz" followed by "git remote add frotz" work?
>
> To me it feels wrong to allow the user to set the default remote to something
> that doesn't actually exist.  It's like trying to add a non-existent file.

Every few weeks, I do this:

	ln -f -s Documentation/RelNotes/$new_version.txt RelNotes
        edit Documentation/RelNotes/$new_version.txt

> And what if the user forgets the second step?

That is why we warn on an unusual order. A lazy "git push" will fail and that would be sufficient clue.

And another reason for the warning (with "you do not yet have") is to prevent this:

	git remote add frotz git://over.there.xz/git.git
        git remote default frozt

> It seems saner for a command to fail if it knows a change it's about to make
> will cause problems.

The point is that you do *NOT* know it will cause problems. People who want to do things in an unusual order *know* what they are doing a lot better than you do. Don't get in their way.