Re: fast-forward only policy



Hi,

On Wed, May 6, 2009 at 3:52 PM, Felipe Contreras
<felipe contreras gmail com> wrote:
> On Wed, May 6, 2009 at 6:44 AM, Elijah Newren <newren gmail com> wrote:
>> On Tue, May 5, 2009 at 4:24 PM, Felipe Contreras
>> <felipe contreras gmail com> wrote:
>>> On the other hand 'gnome-2-0' is not pointing to any release, there
>>> where commits after the last release. So my question here is: who
>>> would care about those commits? They were done 6 years ago and nobody
>>> made a tag that contains them. The arguments I've heard apply to the
>>> stable releases (GEDIT_2_0_5), if somebody wants to create a GNOME 2.0
>>> build, or make GEDIT_2_0_6 release, they'll probably go for the latest
>>> code that was actually released and used.
>>
>> I disagree; I think they'd check out the branch and use it;
>> particularly since that has been the practice for a number of years
>> now.  But that's only one side of the issue, and the less interesting
>> one at that...
>
> *sigh*
>
> Do this command:
> $git checkout GEDIT_2_0_5
>
> Then do 'git branch'. What do you see? "(no branch)" Of course,
> completely unintuitive, how contributors are expected to create a
> 2.0.6 release under such hard conditions!
>
> Well, now do this command:
> $git checkout origin/gnome-2-0
>
> What does 'git branch' show this time? "(no branch)" Ah, much better!
> Now contributors will be on their element.
>
> Creating a local branch is a step that you need to do on both cases,
> there's no difference whatsoever.

That's kind of orthogonal to the point I was making and responding to.
 I was responding to your two comments, "who would care about those
commits" and "if somebody wants to create a GNOME 2.0 build, or make
GEDIT_2_0_6 release, they'll probably go for the latest code that was
actually released and used."  Using the GEDIT_2_0_5 tag vs. the
origin/gnome-2-0 branch give you different answers, since the branch
may have advanced past the tag; so there's a decision to be made.  You
have consistently claimed that those commits on the branch were
useless and no one would even look at them, and I was pointing out
historical precedent that was in conflict with this assumption of
yours.

> I express concern because when you use git properly branches are a
> central part of development (unlike other SCMs) therefore you *see*
> these branches all the time, which is annoying.

I agree.

> I understand the need for such branches like 'gnome-2-20'. It's
> unlikely, but some one might make a release out of that. But
> 'gnome-2-0'?

Maybe I missed your switch, but I thought you had been advocating
'master' and 'devel' and getting rid of 'gnome-2-x' branches until
today.  So I was responding to that.

I agree it'd be nice to move known-to-be-unused branches to some
archival or legacy area (refs/archive/*, refs/legacy/*?).  You just
have to be reasonably certain they are really unused (no enterprise
distro could possibly be using them anymore, etc.).  I'm guessing
there's very few gnome-2-x branches that are ready for archiving by
now.

> Do you seriously think because git.git is maintained by Junio nobody
> else has a clone of that repo? Of course not! Every git developer had
> a clone, and they all saw the maint branches. Some might have have
> work on top of those branches.
>
> Why didn't the world fell to pieces when Junio removed those branches?
> git is *distributed* if you have local main-1.6.0 branch with 4
> commits and Junio removes the branch what happens? Nothing, you only
> see that "origin/main-1.6.0" was removed, big deal. Your local
> main-1.6.0 remains intact.

I must have done a really poor job communicating; sorry about that.
You had been advocating only having 'master' and 'stable' branches.  I
was pointing out that even git.git went further than that and had the
equivalent of stable-x.y branches, and that I thought we would need
those too.  I figured you'd say, "yes, but they have since been
deleted in git.git", and so I proceeded to point out why I think gnome
is different and would need to keep several of those stable-x.y
branches around for a long time and not delete them.

> Yes, but what about branches like CORBA_ENABLED, GEDIT_VIEW, GNOME_MDI.

Oh, I'm a big fan of archiving old branches like these; that sounds
great.  I just think the gnome-2-x branches will need to be around
longer (e.g. rhel4 is still supported and ships with gnome 2.8), but
it sounds like you're now in agreement with that.


I hope this email is a bit clearer than my last; sorry about that.

Elijah


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]