Re: fast-forward only policy

[Felipe Contreras <felipe contreras gmail com>]

On Wed, May 6, 2009 at 6:44 AM, Elijah Newren <newren gmail com> wrote:
> Hi,
>
> 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.

> The reason these branches were created and kept was not merely because
> subversion and cvs suck and can't reasonably delete old branches.  Due
> to the various enterprise distributions, developers needed to continue
> to apply patches and make other fixes to versions of the code that
> were several years old and they were duplicating each others' work.
> They had trouble discovering when others were doing similar backports
> and where their work was.  So there was an effort to standardize old
> branch names to make it easy to know where to put their fixes, and
> where other developers could go to find them; these fixes were often
> not straightforward backports given the divergence of the development
> branch and these old versions.  (I believe it was started by an email
> from Federico on desktop-devel-list, but it's been so many years that
> my memory may be faulty there.) Yes, people decided that it was okay
> for developers to commit their fixes without maintainer approval to
> otherwise "unsupported" branches for this particular use.  Think what
> you will of that solution, but if you delete these old branches you
> will make finding and/or recording such fixes harder.  Those 6 patches
> that are not part of any tag are evidence that the old system was
> being used.  (I don't know if this is the optimal solution to the
> problem, particularly given the better VCS available to us today, but
> it was certainly low cost and made people happy.  I believe this email
> thread is the first time in years anyone has expressed any issues with
> that decision.)

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

> Even in git.git there were maint-1.5.1, maint-1.5.4, maint-1.6.0, and
> maint-1.6.1 branches, in addition to the standard pu, next, master,
> and maint (check the log; you'll see the evidence these were there).
> Since only Junio can push to git.git, he can create or delete branches
> as he wants without affecting others; so he can (and did) delete these
> branches once he knew they were no longer active.  But we have
> multiple people accessing git.gnome.org, and others may be using these
> old branches for years after most consider them to no longer be
> 'active'.  Since they were particularly there for people who were
> _not_ the maintainer, the maintainer can't really know when they
> aren't being used anymore.  (Maybe we could try to find out when a
> particular version is no longer being used in *any* stable or
> enterprise distribution?  I bet we could kill the 1.x branches, but
> Solaris would probably cause us to keep all the 2.x ones around.)

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.

> Yes, I understand the desire to clean things up; it's nice to prune
> stuff that's "not used" in git, especially since it is so easy to
> recreate or even work without it.  However, these branches really do
> have a reason and do have an important (though infrequent) use; so
> unless you can come up with a convincing proposal for an alternate way
> to handle these issues (and I may not be remembering all the issues
> either), *and* can convince others that adopting a new mechanism and
> trying to get it disseminated to everyone (which isn't easy due to
> this being an infrequent use case and the fact of how few read
> desktop-devel-list and even devel-announce-list) and show that it
> should be less of a cost than keeping some branches around that appear
> to be unused, then it's really unlikely that such a change will occur.
>
> I think you could easily come up with such a proposal that I would not
> have a problem with in my personal use (I don't like lots of branches
> for the public repositories either); however, I'm not sure that others
> are going to see changing a policy that will take time to communicate
> to everyone is worth the cost of making things a little bit tidier for
> you and me.  So I'm betting on a very uphill battle if you want to
> pursue this; I certainly don't see the cost/benefit tradeoff as being
> very encouraging and wouldn't put my time into it.
>
> Anyway, I hope that at least provides some perspectives on why these
> things exist and why you're seeing people oppose your proposal.

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

-- 
Felipe Contreras