Re: renaming remote branches

From: Jeff King <peff@peff.net>
Date: Apr 17, 2009, 12:07 UTC
Message-ID: <20090417120741.GD29121@coredump.intra.peff.net>
In-Reply-To: <buomyagf6g7.fsf@dhlpc061.dev.necel.com>

On Fri, Apr 17, 2009 at 09:51:36AM +0900, Miles Bader wrote:

> E.g., a project has a long-term public branch "oink" which is finally
> merged to master, and thereafter ceases to be kept up-to-date.
> Sometimes the developers are reluctant to delete it becaue they want to
> keep the history around.  However simply leaving it in place can be

For some definition of "history", I suppose. Everything of interest should now be part of the history of "master", except:

  1.  you can no longer refer to the branch by name (but why would you
      want to, if it is now obsolete?)

  2. the reflog history for oink would be gone (but that will be gone
     anyway after the 90-day expiration period)

So I think it is a case of those developers being overly cautious. But I respect the fact that it is sometimes easier to simply move the branches than try to convince them otherwise.

If you were keeping reflogs forever for auditing purposes (as has been discussed elsewhere in the thread about gentoo), then I can see some point to (2). But in such a workflow, your "delete and create" strategy doesn't help at all, as the reflog is still purged. You would want to disable branch deletion entirely in such a workflow, and use a first-class move command. So a first-class "move remote branch" operation would be useful there.

-Peff