On Thu, Apr 16, 2009 at 09:09:17AM -0400, Jay Soffian wrote: > On Thu, Apr 16, 2009 at 2:59 AM, Jeff King <peff@xxxxxxxx> wrote: > > Not only is this not user-friendly, but it does not preserve any branch > > config or reflog at the remote (both things that "branch -m" does). > > I wonder whether we should: > > a) teach git remote a rename-branch sub-command I think that is a reasonable place for such a helper command to go, whether it is tightly integrated with git or not (IOW, even with nothing else, it might still be useful to have a wrapper to parse the remote hostname and directory from the config, ssh in, and run "git branch -m"). > b) add support on the remote side for properly preserving the config and reflog Do you mean over the git protocol? I don't see a real reason not to have it (since we allow deletion already, the user is not doing anything more destructive than what we already do). But I think any proposal would have to spell out how the protocol could accomodate this in a backwards-compatible manner. I wonder if we could simply do "rename detection" on the list of pushed refs, and save the config and reflog in that case. IOW, detect git push remote remote/foo:refs/heads/bar :refs/heads/foo I think there is fundamentally a race condition with the "create new and delete old" approach, though, as nothing is guaranteeing that your "new" and the remote's "old" have the same thing in them. You might be deleting somebody else's new commits, no "--force" required. So probably it is better to be able to explicitly specify a rename. All of that is assuming that remote renames are common enough to really care about. Personally, I've never actually done one. -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