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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
