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

On Thu, Jul 5, 2012 at 6:11 PM,  [off-list ref] wrote:

From: Marc Branchaud <redacted>

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.

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.

Phil