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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list