2009/3/5 Andreas Ericsson <ae@xxxxxx>: > Finn Arne Gangstad wrote: >> >> Sorry to people receiving this mail twice, the list ate my first reply >> since it managed to hit the spam-filter (maybe I should take a hint... :) >> >> On Tue, Feb 24, 2009 at 11:01:38PM -0800, Junio C Hamano wrote: >>> >>> [...] >>> >>> But if you are talking about changing the default when "git push" is run >>> without any parameter, I have to say it is a terrible idea, for two >>> reasons, and one is too obvious to state so I wouldn't repeat it and talk >>> only about the other one. >> >> The current default behaviour of git push is very annoying for us at >> least. The current behaviour is _dangerous_ and leads to serious >> problems. It is too easy for someone to write "git push". They hit >> enter too soon, or they write it expecting to get usage >> information. They do not necessarily expect to overwrite random >> branches in a remote repository. >> >> Most git commands are not destructive with no arguments at all, and >> push is the _only_ command that really can screw things up for others, >> so this command in particular should refrain from destructive default >> behaviour. >> >> An example of random branch overwriting: >> $ mkdir a >> $ cd a >> $ git init >> $ echo contents > file >> $ git add file >> $ git commit -m message >> $ cd .. >> $ git clone a b >> $ cd b >> $ git checkout -b gif-support >> $ echo foo > somefile >> $ git add somefile >> $ git commit -m message >> $ ( cd ../a && git branch gif-support) # Assume done by someone else >> $ git checkout master >> $ # <hack away, maybe commit a bit> >> $ git push # <-- OOOPS! pushes gif-support! >> >> Notice that what branches git push ends up pushing is out of your >> control, since new branches can appear in the remote repository at any >> time. This is very unfriendly in our setup with a shared incoming repo. >> >> If developer A creates "gif-support", shares it with developer B, who >> does an additional commit on it to make it print more debug info (but >> has no intent of pushing it anywhere), and A pushes it to the "incoming" >> repo, developer B risks overwriting that with his debug version. >> > > git push will never overwrite changes in the remote repo unless you > specify --force. If anyone *blindly* uses --force, they really shouldn't > have write-access to anything so precious as your code repositories. It's seems a very likely scenario to me. I work on a remote branch with one other person, to make some new feature. Once we are done, I rebase and get rid of the cruft from the history, then "git push --force" to update the branch. Whoops, I've just unknowingly wiped out a completely different branch. > > Worst-case scenario, you commits that were never intended for publication > enter your public wateringhole and needs a revert later on. Big deal. > >> 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. > >>> If you shoot for the least damage for such people, the sanest default for >>> "git push" would be to do nothing. You *always* say what to push where, >>> then there is no risk of pushing something you did not intend to. >>> Perhaps >>> "push.default = never" configuration may not be such a bad idea? >> >> 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. If people don't agree on changing 'git push' to affect only the current branch, I would also go for making 'git push' a noop. John > > -- > Andreas Ericsson andreas.ericsson@xxxxxx > OP5 AB www.op5.se > Tel: +46 8-230225 Fax: +46 8-230231 > > Considering the successes of the wars on alcohol, poverty, drugs and > terror, I think we should give some serious thought to declaring war > on peace. > -- 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
