7 ms·

Although the responsible developer's reaction and attitude are both commendable, one element of his response annoyed me: his continued assertion that he should

by nathanb 13y ago

Although the responsible developer's reaction and attitude are both commendable, one element of his response annoyed me: his continued assertion that he should not have been allowed to do this thing that he did. I think it is a truism that systems which allow users to do interesting and clever things must also allow users to do remarkably stupid and wrong things. Rather than focusing on how to prevent a user from doing a silly thing like this, I think a well-designed tool would easily allow the user to undo the silly thing he just did. Unfortunately, all too often when a Bad Thing happens, the discussion tends to center around how to prevent this Bad Thing from happening again. This is often why those who make mistakes end up being demonized; their mistake has now limited the actions that every other user of the system can make, because the system will be modified to prevent other users from making the same mistake.

btown 13y ago
That said, sometimes Bad Thing Prevention is something that should have been implemented long ago, and was hitherto unrecognized. My canonical example is increased regulations and requirements for entry when an untrained student was seriously injured in a university machine shop; training is something that can be attained, just as "being the one at the top of the organization with force push access" is something that can be attained. There's no loss of abilities, just a more-optimal mapping of abilities to the people who know how to use them.
- bad_user 13y ago
  Given that Git is such an integral part of the workflow, I find unnacceptable the ability to push to the central repo for people that can't handle Git well. Git is distributed, if you're using it like it's SVN you're doing it wrong. And yes, we all make mistakes. But by Git's nature, lo and behold, everybody has a copy.
  - ihateloggingin 13y ago
    This has nothing to do with git. It has to do with github. Git already prohibits forced pushes if you use 'git init --shared' to create your repo.
kohlhofer 13y ago
great sentiment.
finnw 13y ago
http://www.youtube.com/watch?v=-8oH8JHaE00 http://www.youtube.com/watch?v=-8oH8JHaE00
astral303 13y ago
More systems need to implement undo (and scalable undo). Hiding behind "are you sure? (Y/N)" type of prompts and saying "Well, you really should've checked that thrice before hitting Enter" is not good enough.
- aristidb 13y ago
  Yes! And git already gives all the pieces to make this work. (Specifically the reflog.)
  - jlgreco 13y ago
    Being able to write custom update hooks also allows you to do a lot of neat things (in this case, an update hook could prevent non-fastforward pushes).
    - crbnw00ts 13y ago
      You can already do this with git config, but unfortunately it's a giant hammer that affects the entire repo at once. It is of course possible to write a post-receive hook that denies non-fastforward pushes to specific branches, but really, git should include a config option out of the box to do this at a more granular level. A common workflow is the expectation that people should be able force-push to their own topic branches all they like, but never to the default branch (except in extreme circumstances). Being able to easily set this via a config option would be very helpful in keeping working repos more "safe" from this kind of thing.
      - jlgreco 13y ago
        Ideally personal topic branches, not yet ready for world consumption, would be pushed but to a different repo. This would allow the main repo to have a global "No force pushes!" setting, and would prevent branch name collisions (how many developers have a scratch branch sitting around named 'scratch'?)
        13y ago
Silhouette 13y ago
I think it is a truism that systems which allow users to do interesting and clever things must also allow users to do remarkably stupid and wrong things. Rather than focusing on how to prevent a user from doing a silly thing like this, I think a well-designed tool would easily allow the user to undo the silly thing he just did. Isn't that exactly what a revision control system is for?
- darkarmani 13y ago
  > Isn't that exactly what a revision control system is for? Unfortunately, some allow you to re-write all history.
  - Silhouette 13y ago
    Right. So if your revision control system -- your failsafe in the event of unpredicted mistakes -- is configured such that you can lose data permanently, I think it is fair to ask whether anything can be changed to improve how that tool operates. This doesn't mean you can't also ask what else might be done to avoid any unfortunate repetition of the same problem situation, of course.
    - jrochkind1 13y ago
      Nothing was or could have been lost permanently. The commits were all still there, it's just that none of them were in the commit history for any branches anymore. And the entire history including sufficient info to restore the state prior to the `push -f` is all there in the reflog. It's just a pain in the butt to restore it all, especially if in the meantime people started making new commits on top. But if someone has commit privileges to a repo, they have the ability to mess it up, I don't see any real way around that. The UI of the client side tool(s) that made it so easy to make this mistake can perhaps be blamed.
      - eru 13y ago
        > But if someone has commit privileges to a repo, they have the ability to mess it up, I don't see any real way around that. Force push capabilities make it even easier to mess up than just plain commit priviliges.
darkarmani 13y ago
> his continued assertion that he should not have been allowed to do this thing that he did. Why? How does taking away force permission on repos he doesn't commit to prevent him from doing clever things?
- jwecker 13y ago
  The fact that there's no immediate obvious answer is what makes it by definition clever.
mhurron 13y ago
Good access controls prevent people from doing things they shouldn't. This includes: -People that shouldn't have access -People that do have access but can make mistakes or shouldn't have complete, unrestricted access -Processes that shouldn't have access -Processes that do have access going haywire He is right, done properly, this probably shouldn't have been allowed to happen. edit: it's almost readable now
- nathanb 13y ago
  From my reading of his post, the one big failure of the system is that he had an access he didn't think he had. This is sort of like me typing find . | xargs -n0 rm -rf in the root directory and thinking "it's OK because it will only delete files I have permission to delete" but not realizing that I'm root. I could certainly see the argument that the system should have made him more aware of the permissions he had. But it seems like instead he's arguing that he shouldn't have been given those permissions to begin with, which goes back to my point. Because one person was given many permissions and used them irresponsibly, now everyone's default permissions are more restrictive.
kevrone 13y ago
I'm pleased that the reaction in this thread is generally with understanding towards the developer. We've all had facepalm moments like this, and probably not as publicly. But I don't think Bad Thing Prevention is necessarily to be avoided. Undo buttons are sweet, but not everything can be undone. An anecdote: During the first month of my first job in finance I accidentally deleted a few mappings in a database which put the entire company at risk to the tune of about $45million. Complete bone-head move, I was new to the game. It all turned out fine and I got off with a slap on the wrist, but my manager was flogged. When markets are involved, something like that has no undo button. Instead, we put some proper controls in place (tests, mostly) to make sure said mappings were always logically consistent. As far as I know, that brand of problem has not occurred in the 6 years since.
munificent 13y ago
> I think a well-designed tool would easily allow the user to undo the silly thing he just did. Agreed. From a usability perspective, undo is always best. Especially undo that the user: 1) knows about, 2) trusts, and 3) is fast. That encourages exploration and lets users fix mistakes. > their mistake has now limited the actions that every other user of the system can make, because the system will be modified to prevent other users from making the same mistake. I don't think this is a black and white issue. It's not about denying all users the ability to express X ever again. I think it's more about having systems that can tell if X is an unusual or heavyweight action and say, "Hey, you're about to do X, which impacts a lot of stuff and you've never done before. Are you sure that's what you mean?" It's velvet rope permissions, not a locked door.
- gcb0 13y ago
  that's why a have a easy to type password to unlock my local private key, and i set my keymanager to never cache the password. It is always nice to have that last chance to review your changes to the VCS. ...not that it would have helped in this case as he was probably using it heedlessly in a jenkins plugin.
- icebraining 13y ago
  I don't think this is a black and white issue. It's not about denying all users the ability to express X ever again. I think it's more about having systems that can tell if X is an unusual or heavyweight action and say, "Hey, you're about to do X, which impacts a lot of stuff and you've never done before. Are you sure that's what you mean?" Yes, but git already does that, by having the user type "--force". Asking would eliminate the possibility of scripting the action.
  - davvolun 13y ago
    That's not entirely accurate, e.g. "git push --force --yes" would still be perfectly scriptable.
    - bereft_orange 13y ago
Havoc 13y ago
Well I think one needs both permission control and easy undo options. His insistence that he should not have had right access does come across as a lame excuse, but he has a point. e.g. Take the other poster in the thread who was surprised to find that others have access to his project beyond the half a dozen he knew about - that to me indicates that something isn't quite right permissions-wise.
tinco 13y ago
There is a very simple undo, just force push the branch you just deleted? It's not like force pushing is some terrible destructive thing, it just puts the repo in a state people don't expect.
grmarcil 13y ago
Is version control really an area where the ability to do "interesting and clever" things is desirable?
lectrick 13y ago
> must also allow users to do remarkably stupid and wrong things. These systems can at least put up speed bumps ("are you SURE you want to do this potentially work-imploding operation?") for those sorts of things.
- ihateloggingin 13y ago
  Speed bumps such as being required to specify --force?
ihateloggingin 13y ago
> his continued assertion that he should not have been allowed to do this thing that he did. Well, if the repositories were created with "git init --shared" then it wouldn't have been allowed. I think it's a valid position to believe that this should be the default on github, although obviously in this case, there might be blame-shifting motivation to that position. > Rather than focusing on how to prevent a user from doing a silly thing like this, I think a well-designed tool would easily allow the user to undo the silly thing he just did. Git does make it easy for the user to undo this. It provides the reflog for that. It also provides information in the output of the push command. (However, github does not allow users to access the remote reflog.) In any case, you can blame github, and you can blame the developer, but at least we should all be clear that you can't blame git.

by nathanb 13y ago

btown 13y ago

That said, sometimes Bad Thing Prevention is something that should have been implemented long ago, and was hitherto unrecognized. My canonical example is increased regulations and requirements for entry when an untrained student was seriously injured in a university machine shop; training is something that can be attained, just as "being the one at the top of the organization with force push access" is something that can be attained. There's no loss of abilities, just a more-optimal mapping of abilities to the people who know how to use them.

bad_user 13y ago
Given that Git is such an integral part of the workflow, I find unnacceptable the ability to push to the central repo for people that can't handle Git well. Git is distributed, if you're using it like it's SVN you're doing it wrong. And yes, we all make mistakes. But by Git's nature, lo and behold, everybody has a copy.
- ihateloggingin 13y ago
  This has nothing to do with git. It has to do with github. Git already prohibits forced pushes if you use 'git init --shared' to create your repo.

kohlhofer 13y ago

great sentiment.

finnw 13y ago

http://www.youtube.com/watch?v=-8oH8JHaE00 http://www.youtube.com/watch?v=-8oH8JHaE00

astral303 13y ago

More systems need to implement undo (and scalable undo). Hiding behind "are you sure? (Y/N)" type of prompts and saying "Well, you really should've checked that thrice before hitting Enter" is not good enough.

aristidb 13y ago
Yes! And git already gives all the pieces to make this work. (Specifically the reflog.)
- jlgreco 13y ago
  Being able to write custom update hooks also allows you to do a lot of neat things (in this case, an update hook could prevent non-fastforward pushes).
  - crbnw00ts 13y ago
    You can already do this with git config, but unfortunately it's a giant hammer that affects the entire repo at once. It is of course possible to write a post-receive hook that denies non-fastforward pushes to specific branches, but really, git should include a config option out of the box to do this at a more granular level. A common workflow is the expectation that people should be able force-push to their own topic branches all they like, but never to the default branch (except in extreme circumstances). Being able to easily set this via a config option would be very helpful in keeping working repos more "safe" from this kind of thing.
    - jlgreco 13y ago
      Ideally personal topic branches, not yet ready for world consumption, would be pushed but to a different repo. This would allow the main repo to have a global "No force pushes!" setting, and would prevent branch name collisions (how many developers have a scratch branch sitting around named 'scratch'?)
      - 13y ago

Silhouette 13y ago

I think it is a truism that systems which allow users to do interesting and clever things must also allow users to do remarkably stupid and wrong things. Rather than focusing on how to prevent a user from doing a silly thing like this, I think a well-designed tool would easily allow the user to undo the silly thing he just did. Isn't that exactly what a revision control system is for?

darkarmani 13y ago
> Isn't that exactly what a revision control system is for? Unfortunately, some allow you to re-write all history.
- Silhouette 13y ago
  Right. So if your revision control system -- your failsafe in the event of unpredicted mistakes -- is configured such that you can lose data permanently, I think it is fair to ask whether anything can be changed to improve how that tool operates. This doesn't mean you can't also ask what else might be done to avoid any unfortunate repetition of the same problem situation, of course.
  - jrochkind1 13y ago
    Nothing was or could have been lost permanently. The commits were all still there, it's just that none of them were in the commit history for any branches anymore. And the entire history including sufficient info to restore the state prior to the `push -f` is all there in the reflog. It's just a pain in the butt to restore it all, especially if in the meantime people started making new commits on top. But if someone has commit privileges to a repo, they have the ability to mess it up, I don't see any real way around that. The UI of the client side tool(s) that made it so easy to make this mistake can perhaps be blamed.
    - eru 13y ago
      > But if someone has commit privileges to a repo, they have the ability to mess it up, I don't see any real way around that. Force push capabilities make it even easier to mess up than just plain commit priviliges.

darkarmani 13y ago

> his continued assertion that he should not have been allowed to do this thing that he did. Why? How does taking away force permission on repos he doesn't commit to prevent him from doing clever things?

jwecker 13y ago
The fact that there's no immediate obvious answer is what makes it by definition clever.

mhurron 13y ago

Good access controls prevent people from doing things they shouldn't. This includes: -People that shouldn't have access -People that do have access but can make mistakes or shouldn't have complete, unrestricted access -Processes that shouldn't have access -Processes that do have access going haywire He is right, done properly, this probably shouldn't have been allowed to happen. edit: it's almost readable now

nathanb 13y ago
From my reading of his post, the one big failure of the system is that he had an access he didn't think he had. This is sort of like me typing find . | xargs -n0 rm -rf in the root directory and thinking "it's OK because it will only delete files I have permission to delete" but not realizing that I'm root. I could certainly see the argument that the system should have made him more aware of the permissions he had. But it seems like instead he's arguing that he shouldn't have been given those permissions to begin with, which goes back to my point. Because one person was given many permissions and used them irresponsibly, now everyone's default permissions are more restrictive.

kevrone 13y ago

I'm pleased that the reaction in this thread is generally with understanding towards the developer. We've all had facepalm moments like this, and probably not as publicly. But I don't think Bad Thing Prevention is necessarily to be avoided. Undo buttons are sweet, but not everything can be undone. An anecdote: During the first month of my first job in finance I accidentally deleted a few mappings in a database which put the entire company at risk to the tune of about $45million. Complete bone-head move, I was new to the game. It all turned out fine and I got off with a slap on the wrist, but my manager was flogged. When markets are involved, something like that has no undo button. Instead, we put some proper controls in place (tests, mostly) to make sure said mappings were always logically consistent. As far as I know, that brand of problem has not occurred in the 6 years since.

munificent 13y ago

> I think a well-designed tool would easily allow the user to undo the silly thing he just did. Agreed. From a usability perspective, undo is always best. Especially undo that the user: 1) knows about, 2) trusts, and 3) is fast. That encourages exploration and lets users fix mistakes. > their mistake has now limited the actions that every other user of the system can make, because the system will be modified to prevent other users from making the same mistake. I don't think this is a black and white issue. It's not about denying all users the ability to express X ever again. I think it's more about having systems that can tell if X is an unusual or heavyweight action and say, "Hey, you're about to do X, which impacts a lot of stuff and you've never done before. Are you sure that's what you mean?" It's velvet rope permissions, not a locked door.

gcb0 13y ago
that's why a have a easy to type password to unlock my local private key, and i set my keymanager to never cache the password. It is always nice to have that last chance to review your changes to the VCS. ...not that it would have helped in this case as he was probably using it heedlessly in a jenkins plugin.
icebraining 13y ago
I don't think this is a black and white issue. It's not about denying all users the ability to express X ever again. I think it's more about having systems that can tell if X is an unusual or heavyweight action and say, "Hey, you're about to do X, which impacts a lot of stuff and you've never done before. Are you sure that's what you mean?" Yes, but git already does that, by having the user type "--force". Asking would eliminate the possibility of scripting the action.
- davvolun 13y ago
  That's not entirely accurate, e.g. "git push --force --yes" would still be perfectly scriptable.
  - bereft_orange 13y ago

Havoc 13y ago

Well I think one needs both permission control and easy undo options. His insistence that he should not have had right access does come across as a lame excuse, but he has a point. e.g. Take the other poster in the thread who was surprised to find that others have access to his project beyond the half a dozen he knew about - that to me indicates that something isn't quite right permissions-wise.

tinco 13y ago

There is a very simple undo, just force push the branch you just deleted? It's not like force pushing is some terrible destructive thing, it just puts the repo in a state people don't expect.

grmarcil 13y ago

Is version control really an area where the ability to do "interesting and clever" things is desirable?

lectrick 13y ago

> must also allow users to do remarkably stupid and wrong things. These systems can at least put up speed bumps ("are you SURE you want to do this potentially work-imploding operation?") for those sorts of things.

ihateloggingin 13y ago
Speed bumps such as being required to specify --force?

ihateloggingin 13y ago

> his continued assertion that he should not have been allowed to do this thing that he did. Well, if the repositories were created with "git init --shared" then it wouldn't have been allowed. I think it's a valid position to believe that this should be the default on github, although obviously in this case, there might be blame-shifting motivation to that position. > Rather than focusing on how to prevent a user from doing a silly thing like this, I think a well-designed tool would easily allow the user to undo the silly thing he just did. Git does make it easy for the user to undo this. It provides the reflog for that. It also provides information in the output of the push command. (However, github does not allow users to access the remote reflog.) In any case, you can blame github, and you can blame the developer, but at least we should all be clear that you can't blame git.