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
--
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