Re: Removing options from build

From: R. Tyler Ballance <tyler@slide.com>
Date: Jan 13, 2009, 22:00 UTC
Message-ID: <1231884045.14181.36.camel@starfruit>
In-Reply-To: <200901132253.15370.trast@student.ethz.ch>

On Tue, 2009-01-13 at 22:53 +0100, Thomas Rast wrote:

Show 11 quoted lines

> R. Tyler Ballance wrote:
> > Besides a vigorous flogging, we're looking at other ways to prevent this
> > sort of thing from happening again; the option we've settled on is to
> > remove the "--force" flag from our internal build of v1.6.1
> >
> > I'm wondering if somebody could point me in the right direction to
> > remove "--force" (safely) from the builtin-push.c and removing the
> > "rebase" command (we've got no use for it, and would prefer it gone).
> 
> IMHO your update (or pre-receive) hook should just disallow
> non-fast-forward updates.

Don't merges count as non-fast-forward updates? We generate merge commits with almost every merge, rarely do we actually have fast-forwards anymore (highly active repository)

Show 5 quoted lines

> 
> This doesn't really address git-rebase, but it will disallow pushing a
> "harmfully" rebased branch since those are by definition non-ff.  Why
> take away the option to correct a mistake in the last commit with 'git
> rebase -i'?

I'm a strong proponent of revision history only moving forward, I would much rather see a series of revert commits than having somebody who is inexperienced with the tools they're using muck about an jeopardize the stability of our central repository.

Used correctly, both --force and `rebase` have good reason to exist in the Git codebase; they just haven't been used correctly, and proper bamboo to flog developers with will take a couple days to ship from Asia, so removing the options from our internal build is a lot easier and faster ;)

Cheers :D

-- 
-R. Tyler Ballance
Slide, Inc.