On 12-07-06 08:51 AM, Phil Hord wrote: > On Thu, Jul 5, 2012 at 6:11 PM, <marcnarc@xxxxxxxxxxx> wrote: >> From: Marc Branchaud <marcnarc@xxxxxxxxxxx> >> >> 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. -- 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