Re: fast-forward only policy

[Felipe Contreras <felipe contreras gmail com>]

On Wed, May 6, 2009 at 1:53 AM, Vincent Untz <vuntz gnome org> wrote:
> Le mercredi 06 mai 2009, à 01:24 +0300, Felipe Contreras a écrit :
>> On Wed, May 6, 2009 at 1:00 AM, Vincent Untz <vuntz gnome org> wrote:
>> > No. It points to the latest code in the 2.24 branch. There might be code
>> > after the release. It's a branch, it's not a tag. So, maybe I don't
>> > understand what you're saying because I misunderstand git?
>>
>> I'm talking about that specific branch in that specific repo:
>> gnome-2-24 -> GEDIT_2_24_3 -> 8372af3
>>
>> 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.
>
> Some distributions might have shipped those patches. The fact that they
> are in the vcs made it easy to share with other distributions who might
> have needed it. Even if there was no release with those changes.

Debian patches are debian patches, they control them, and they make
debian releases. If GNOME decides to remove those commits the
distributions will not loose their patches.

> Or maybe the maintainer really intended to do a release and found out it
> wasn't really needed in the end.

That's a very unlikely situation, it make no sense that everybody
suffers (having gazillions of branches) just because of that.

If you really want to be safe you can create legacy (hidden) repos in
the case someone might need those commits. They will not waste any
space because git uses hard links when you clone locally. Then you can
delete all the legacy branches in the public (visible) repos while
still be confident no commit will be lost.

> [...]
>
>> Now, let's suppose GTK+ is a truly independent project, and their
>> independent repo (non-gnome) is in git.gtk.org. Just like you can
>> create arbitrary branches in your local repo, you can do the same in
>> git.gnome.org.
>>
>> So what I'm trying to say is: even if GTK+ is an independent project,
>> GNOME maintainers can still add their own branches in their own repos.
>> After all you are prefixing the branches with 'gnome-' so it should
>> not conflict with GTK+ branches. Right?
>
> I guess I'm lost here, since this seems to be another topic (or maybe
> you're getting back to the original topic in the thread). Sure,
> maintainers are free to push any branches they want.

There's nothing wrong with adding gnome-major-minor branches on
"independent" projects on the git.gnome.org repos.

Maybe this would help. Let's say we have git.maemo.org where we have a
GTK+ repo, we don't have any changes on top of that (hypothetical),
but we want some branches to keep track of our releases, so we add a
'maemo-2.0' branch that essentially points to 'gnome-2-24'.

Should GNOME care what branches are in git.maemo.org that are not in
git.gnome.org? No. It's DSCM, the owner of the repo can do whatever
they want, so GNOME can add any 'gnome-' branches they want to
git.gnome.org because GNOME owns those repos.

-- 
Felipe Contreras