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

From: Phil Hord <phil.hord@gmail.com>
Date: Jul 6, 2012, 12:51 UTC
Message-ID: <CABURp0oYfzKrkKOZJrH2hrYMTPbFe_i5mMKQ3HnWQdGZa=oujw@mail.gmail.com>
In-Reply-To: <1341526277-17055-5-git-send-email-marcnarc@xiplink.com>

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.

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