From: John Tapsell <johnflux@gmail.com>
To: Andreas Ericsson <ae@op5.se>
Cc: Finn Arne Gangstad <finnag@pvv.org>,
Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: git push
Date: Thu, 5 Mar 2009 08:56:43 +0000 [thread overview]
Message-ID: <43d8ce650903050056v4b7a22cfve2eb4d8d76717285@mail.gmail.com> (raw)
In-Reply-To: <49AF9117.1020407@op5.se>
2009/3/5 Andreas Ericsson <ae@op5.se>:
> 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@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.
>
next prev parent reply other threads:[~2009-03-05 8:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-25 6:38 git push John Tapsell
2009-02-25 6:46 ` Jeff King
2009-02-25 7:01 ` Junio C Hamano
2009-02-25 7:09 ` John Tapsell
2009-02-25 7:44 ` Junio C Hamano
2009-02-25 9:02 ` Jeff King
2009-02-25 9:26 ` Junio C Hamano
2009-02-25 9:51 ` Jeff King
2009-02-25 9:08 ` John Tapsell
2009-02-25 9:49 ` Junio C Hamano
2009-02-25 10:06 ` John Tapsell
2009-02-25 9:34 ` Jay Soffian
2009-02-25 9:51 ` Junio C Hamano
2009-02-25 22:58 ` Finn Arne Gangstad
2009-03-05 8:45 ` Andreas Ericsson
2009-03-05 8:56 ` John Tapsell [this message]
2009-03-05 9:44 ` Finn Arne Gangstad
[not found] <CAJmx4Nxh_WzkO-S=SN9E=aODCrfs+QCig4sT+Q8eQ+Pv1hB2+w@mail.gmail.com>
2012-03-19 16:24 ` Kevin O'Brien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43d8ce650903050056v4b7a22cfve2eb4d8d76717285@mail.gmail.com \
--to=johnflux@gmail.com \
--cc=ae@op5.se \
--cc=finnag@pvv.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).