Re: Removing options from build

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

R. Tyler Ballance wrote:

quoted

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.