Re: [PATCH] git-remote - Unset core.origin when deleting the default remote

[Jeff King <peff@peff.net>]

On Sun, Jan 13, 2008 at 11:27:08AM -0500, Mark Levedahl wrote:

> --- a/git-remote.perl
> +++ b/git-remote.perl
> @@ -328,6 +328,11 @@ sub rm_remote {
>  
>  	$git->command('config', '--remove-section', "remote.$name");
>  
> +	my $defremote = $git->config("core.origin");
> +	if (defined $defremote && $defremote eq $name) {
> +	       $git->command("config", "--unset", "core.origin");
> +	}
> +

I'm not sure I see the use case that this helps. Presumably you are
doing one of (assuming your core.origin is 'foo'):

  - delete 'foo', and then proceed with usual git commands. In this
    case, your core.origin has reverted to 'origin', but what is the
    chance that you actually have such a remote (since you presumably
    cloned with -o foo)?

  - delete 'foo', then re-add 'foo'. I would expect this to be
    equivalent to editing the config, but as a side effect, your
    core.origin has mysteriously changed.

  - delete 'foo', then re-add 'bar' with the intent of making it your
    new origin. This doesn't help at all, since there's nothing
    automatically setting core.origin to 'bar', so you might as well
    leave it as the bogus 'foo' rather than the bogus 'origin'. And to
    help this use case, something like a "-d" flag to git-remote to set
    the new origin as the default might make sense. I.e.,

      git remote rm foo
      git remote add -d bar git://bar/project.git

    Alternatively, when adding a remote, if it is the _only_ remote (or
    perhaps if the current core.origin doesn't exist), we could set
    core.origin which would automagically cover the latter two cases.
    Although it feels a little too DWIM.

-Peff