On Thu, Mar 05, 2009 at 09:45:11AM +0100, Andreas Ericsson wrote: > Worst-case scenario, you commits that were never intended for publication > enter your public wateringhole and needs a revert later on. Big deal. It could be a very big deal depending on what the contents are. I think you can split developers in two groups - those who like to learn a lot about version control systems, and those who just see it as a necessary evil to get their job done. The latter seems to be the majority. The first group will know how to undo the damage from a bad push (and probably configure their setup so they do not necessarily happen), while the second group will not necessarily notice that it happened or know how to undo it. So, bad pushes go through, and are not detected before 3 other people base their work on it, and we get a lot of hassle. >> It is not realistic to believe that in a big project with many >> developers, no one will ever do the mistake of typing "git push". It >> is also not realistic to believe that everyone will know how to (or >> remember to) configure this away. > > But it *is* realistic to not assume that they will also use --force > while doing so. Our public repos are set up so that only a few chosen people are allowed to force pushes, so this is not an issue for us. >> If "git push" could do nothing at all without configuring anything, that >> would be a big improvement to us. > > I can buy this, I guess. I always type the remote-name I want to push to > anyways. A sane no-op default would probably be to list the pre-configured > remotes along with a short usage message. I still don't quite see the point > of it. I'll try to whip up a small patch series tonight and see what it ends up looking like. - Finn Arne -- 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
