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

[Marc Branchaud <marcnarc@xiplink.com>]

On 12-07-06 08:51 AM, Phil Hord wrote:
> On Thu, Jul 5, 2012 at 6:11 PM,  <marcnarc@xiplink.com> wrote:
>> From: Marc Branchaud <marcnarc@xiplink.com>
>>
>> The "rename" and "rm" commands now handle the case where the remote being
>> changed is the default remote.
> 
> I think this is the right thing to do.  But I noticed a subtle
> behavior change that we may wish to consider.
> 
> Today I might do this (contrived example):
> 
> git checkout somelocalbranch
> git push # pushes to "origin" by default
> git remote rename origin origin1
> git add origin ssh://new-server/foo
> git push  # pushes to "origin" by default
> 
> But after this change, the last command is different.  Now it pushes
> to "origin1" because the rename set the remote.default to "origin1",
> even though it was previously not set at all.  It did this because the
> "oldname" is compared to the "remote_get_default_name()", which
> returns "origin" by default.  So the old setting, which did not exist,
> is now "renamed" to have an actual value, and the actual value is not
> "origin".
> 
> One can easily contrive an alternative example showing that this is a
> good thing.  As I said, I think it is the right thing to do.
> 
> But it is different, I think.

Yes, I agree it is different.

> I doubt many script writers are counting on default settings to carry
> the day, so they are probably more explicit about how they push.  But
> I didn't see this mentioned in the patch.

I think this sort of thing is better suited to the documentation of
remote.default.  I'm planning to re-roll this series with documentation
updates, and I'll include your example.

		M.