Re: fast-forward only policy

[Felipe Contreras <felipe contreras gmail com>]

On Thu, May 7, 2009 at 12:52 AM, Les Harris <lharris gnome org> wrote:
> On Wed, May 6, 2009 at 2:14 PM, Felipe Contreras
> <felipe contreras gmail com> wrote:
>> Would you fight to keep alive the branch Linus just found too crappy
>> and just killed it? If a commit never made it to a release and
>> probably never would, is it really that important?
>
> It seems to me whatever Linus decided to do for the kernel is
> completely orthogonal to what we, the gnome project, decide to do.

Germán argued that the commits are kept for archaeological reasons and
I just showed how the linux project managed to both keep historical
commits and have a clean slate. How is that not relevant?

>> I guess this is like the abortion debate. When is a commit really
>> alive? Does commits feel pain when they are killed before being
>> pushed?
>
> It's probably for the best to keep technical arguments based on
> technical details and not conflate the issue with highly charged and
> emotional topics.
>
> The consensus so far seems to be that losing commits is a non-starter.
>  It's not clear to me what benefit dropping these ossified branches
> gives us.  What is the problem you're trying to solve Felipe?

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?

-- 
Felipe Contreras