Re: Removing options from build

["R. Tyler Ballance" <tyler@slide.com>]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On Tue, 2009-01-13 at 22:53 +0100, Thomas Rast wrote:
> 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)

> 
> 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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]