Re: git push

From: Andreas Ericsson <ae@op5.se>
Date: Mar 5, 2009, 08:45 UTC
Message-ID: <49AF9117.1020407@op5.se>
In-Reply-To: <20090225225826.GA13510@pvv.org>

Finn Arne Gangstad wrote:

Show 51 quoted lines

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

Show 5 quoted lines

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

Show 8 quoted lines

>> 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@op5.se
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.