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