Removing options from build

One of our developers "discovered" the --force option on `git push` and
used it without taking the appropriate care and hosed one of the project
branches we have running around in our central repository.

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

Cheers
-- 
-R. Tyler Ballance
Slide, Inc.

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.

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'?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

On 2009.01.13 13:43:22 -0800, R. Tyler Ballance wrote:

One of our developers "discovered" the --force option on `git push` and
used it without taking the appropriate care and hosed one of the project
branches we have running around in our central repository.

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

git help config

receive.denyNonFastForwards (to refuse non-fast-forwards, even with -f)
receive.denyDeletes (to stop users from working around the non-ff using
                     a delete + recreate operation)

Björn

Thomas Rast wrote:

R. Tyler Ballance wrote:

quoted

I'm wondering if somebody could point me in the right direction to
remove "--force" (safely) from the builtin-push.c

IMHO your update (or pre-receive) hook should just disallow
non-fast-forward updates.

Actually there's even this config option:

       receive.denyNonFastForwards
           If set to true, git-receive-pack will deny a ref update
           which is not a fast forward.  Use this to prevent such an
           update via a push, even if that push is forced. This
           configuration variable is set when initializing a shared
           repository.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

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.

"R. Tyler Ballance" [off-list ref] writes:

One of our developers "discovered" the --force option on `git push` and
used it without taking the appropriate care and hosed one of the project
branches we have running around in our central repository.

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

First, the title (subject) of this email is misleading: it is about
your solution, and not about the problem you have (protecting against
"git push --force").

Second, there are two possible solutions: use receive.denyNonFastForwards
and perhaps also receive.denyDeletes (see git-config(1)) to forbid forced
pushes on server (target of push); removing '--force' is a client solution.
Or, better, use update or post-receive hook on server, forbidding 
non-fastforward updates to selected set of 'stable' branches; you can
use contrib/hooks/update-paranoid for that.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

On Tuesday 2009 January 13 15:43:22 R. Tyler Ballance wrote:

One of our developers "discovered" the --force option on `git push` and
used it without taking the appropriate care and hosed one of the project
branches we have running around in our central repository.

Reflogs should let you recover from this.

Besides a vigorous flogging, we're looking at other ways to prevent this
sort of thing from happening again;

receive.denyNonFastForwards
        If set to true, git-receive-pack will deny a ref update which
        is not a fast forward. Use this to prevent such an update via a
        push, even if that push is forced. This configuration variable
        is set when initializing a shared repository.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

On 2009.01.13 14:00:45 -0800, 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)

No, merges are "fast-forward". In rev-list terms:

git rev-list new_head..old_head ==> Empty

IOW: No commits are lost by the push.

Merges only add commits to the history, they don't remove anything.

Björn

On Tuesday 2009 January 13 16:00:45 R. Tyler Ballance wrote:

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

quoted

IMHO your update (or pre-receive) hook should just disallow
non-fast-forward updates.

Don't merges count as non-fast-forward updates?

No.  If there is a chain of parent links X ~> Y then updating a ref Y -> X is 
a fast-forward.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

On Tue, 2009-01-13 at 16:06 -0600, Boyd Stephen Smith Jr. wrote:

On Tuesday 2009 January 13 15:43:22 R. Tyler Ballance wrote:

quoted

One of our developers "discovered" the --force option on `git push` and
used it without taking the appropriate care and hosed one of the project
branches we have running around in our central repository.

Reflogs should let you recover from this.

quoted

Besides a vigorous flogging, we're looking at other ways to prevent this
sort of thing from happening again;

receive.denyNonFastForwards
        If set to true, git-receive-pack will deny a ref update which
        is not a fast forward. Use this to prevent such an update via a
        push, even if that push is forced. This configuration variable
        is set when initializing a shared repository.

Looks good, thanks; sorry I missed it, didn't even think to look at the
git-config(1) page for such an option. 

I'm assuming this will actually cover the rebase -i case as well?


Cheers

-- 
-R. Tyler Ballance
Slide, Inc.

On Tuesday 2009 January 13 16:18:52 R. Tyler Ballance wrote:

On Tue, 2009-01-13 at 16:06 -0600, Boyd Stephen Smith Jr. wrote:

quoted

receive.denyNonFastForwards
        If set to true, git-receive-pack will deny a ref update which
        is not a fast forward. Use this to prevent such an update via a
        push, even if that push is forced.

Looks good, thanks; sorry I missed it, didn't even think to look at the
git-config(1) page for such an option.

I didn't really know about it until earlier this week.  I was expecting to be 
able to do a non-ff push to one of my repositories and it didn't work because 
this was set "behind my back".  (I'm not sure when it got added, but I don't 
think the shared repositories I set up with git 1.4.4.4 had it, so I wasn't 
expecting it.)

I'm assuming this will actually cover the rebase -i case as well?

I don't know exactly what you mean.  It prevents fast-forwards, so once a 
commit is "visible" on one of your central branches, it won't ever go away.  
(You can, of course, use git revert to undo it's changes.)

As others mentioned, now would be a good time to look at receive.denyDeletes 
and/or a custom hook as well.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

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*