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:
signature.asc
Description: This is a digitally signed message part
