On Tue, 13 Jan 2009, R. Tyler Ballance wrote: > 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) 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. :) > > 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* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
