Re: fast-forward only policy

[Davyd Madeley <davyd madeley id au>]

I have to admit, there is probably some advantage to moving these very
old branches into an archive (either refs/archive/foo or a complete
archive clone) after some amount of time. Mostly because I thought "new
IM? What new IM?".

Also permit the deletion of branches that have been merged with master
(i.e. something that could be deleted with `git branch -d`).

This would probably help people who are not core contributors get an
idea of the state of the project, we have master, a bunch of stable
branches (perhaps we can hack cgit to move stable branches to their own
category on the summary?) and a bunch of active feature branches that
show where people are getting their hands dirty.

On Thu, 2009-05-07 at 01:11 +0300, Felipe Contreras wrote:

> I've already explained that having a gazillion of branches is not
> clear, it creates noise.
> 
> Let's take a look at these from the GTK+ repo:
> 
> themes: 11 years
> themes-2: 11 years
> rendering-demo: 4 years
> ps-mf: 10 years
> master-UNNAMED-BRANCH: 10 years
> kris-async-branch: 3 years
> hp-patches: 9 years
> havoc-patches: 9 years
> gtk-printing: 3 years
> gtk-pango: 9 years
> gtk-no-flicker: 9 years
> gtk-new-im: 9 years
> gtk-multihead: 7 years
> gtk-hp-patches: 9 years
> gdk-object-with-pango: 9 years
> gdk-object: 3 years
> federico-filename-entry: 3 years
> cancelation-changes: 3 years
> AUTO_DENATTIFYING: 3 years
> 
> If you move them to a historic repo, what do you loose?

-- 
Davyd Madeley

http://www.davyd.id.au/
08B0 341A 0B9B 08BB 2118  C060 2EDD BB4F 5191 6CDA