Re: git push

[Finn Arne Gangstad <finnag@pvv.org>]

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.

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.

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

- Finn Arne