Re: fast-forward only policy

[Felipe Contreras <felipe contreras gmail com>]

On Tue, May 5, 2009 at 9:37 AM, John Carr <john carr unrouted co uk> wrote:
> Hi,
>
> On Mon, May 4, 2009 at 9:38 PM, Zeeshan Ali (Khattak) <zeenix gmail com> wrote:
>> Hi,
>>  I was one of the happiest person on this planet the day we moved to
>> git and i can't thanks the people involved enough. Although overall i
>> am pretty happy with the migration, I do have one concern: The policy
>> of disallowing non-fastforward pushes to any branch. I understand that
>> this is good for master and other stable branches, but otoh I think it
>> breaks the usual git workflow for feature branches.
>
> I don't think it does break the usual git workflow. See [1] and [2].
> In particular:
>
> "Rebasing is clearly a useful technique, though. Linus does not tell
> developers not to use it; in fact, he encourages it sometimes. The key
> rule that was passed down is this: Thou Shalt Not Rebase Trees With
> History Visible To Others"

And git.git doesn't follow that rule. Why?

Linux is developed with the chain of trust model; there is no master
repository, every developer has his own repo and they push only to
their own repo. Instead of pushing they send either patches or pull
requests to the relevant maintainer who will review the changes and
ack or nack them. The maintainer then will send his accumulated
patches (or pull request) to the next level up, and so on until it
reaches Linus' tree which is the one most people use, but by no means
the only one.

Note that in Linus' repo there's only one branch ('master'), where the
latest stuff is being developed. If you want the stable kernel, then
you must use another repository that is not maintained by Linus.

git.git doesn't follow that model, instead there is only one master
repository with many branches and there's only one maintainer (Junio).
Everyone must send their changes as patches and only Junio can push
them. Here there are multiple branches, including a moving branch 'pu'
(proposed updates). The 'pu' branch is simply a collection of the
patches sent to the mailing list which are relatively OK but will
possibly change since they still have comments and must be re-send.
This has the advantage that you don't have to hunt down the mailing
list for all the relatively good patches, you can just pick them from
the repository, or just use the 'pu' branch.

GNOME will not follow any of these models, there will be multiple
people pushing to the same repo, so in that sense it's less
distributed. There's another project following a similar model: X.Org.
I'm not sure they even have branch guidelines, but at least they have
user repositories where I guess each developer can do whatever they
want.

So I think you should either allow moving branches such as
'za-transcoding-rework' or have personal repositories on
git.gnome.org.

Cheers.

-- 
Felipe Contreras