Re: Removing options from build

On Tue, 13 Jan 2009, R. Tyler Ballance wrote:

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

quoted

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)

Creating a merge is a non-fast-forward update, but sending the merge to a 
repository that is currently at one of the parents is a fast-forward.

Hopefully, you're generating merge commits with merge, not with push. :)

quoted

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 ;)

Denying non-fast-forward updates means that people can rebase, but if they 
rebase anything that they've pushed (or anyone else has pushed), they 
can't push.

You can't really disallow rebasing of private commits while still using 
git; a user can always clone the upstream repository again, get diffs from 
the repository where they don't like the history, apply them to the new 
clone, and throw away the repository with the bad history. Or they can 
call up a coworker, tell them what changes to make, commit, and push, and 
then lose their work in a hard drive crash. People can always make the 
excuse "My identical twin did stuff wrong, but I knocked him out before 
he could push and did everything right." As long as they can't say "My 
evil twin pushed the changes to the repository's evil twin, but I knocked 
him out and destoryed the evil repository, and now we've got the good 
repository."

	-Daniel
*This .sig left intentionally blank*