From: Sam Vilain <sam@vilain.net>
To: Dmitry Potapov <dpotapov@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
Sam Vilain <samv@vilain.net>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>,
Scott Chacon <schacon@gmail.com>,
Tom Preston-Werner <tom@github.com>,
"J.H." <warthog19@eaglescrag.net>,
Christian Couder <chriscool@tuxfamily.org>,
Kai Blin <kai@samba.org>
Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp
Date: Wed, 05 Nov 2008 07:10:31 +1300 [thread overview]
Message-ID: <1225822231.6722.3.camel@maia.lan> (raw)
In-Reply-To: <20081104091800.GB24100@dpotapov.dyndns.org>
On Tue, 2008-11-04 at 12:18 +0300, Dmitry Potapov wrote:
> > I can see that some people want this behaviour by default; but to me
> > "push the current branch back to where it came from" seems like far more
> > a rational default for at least 90% of users.
>
> I think it depends on one's workflow. If you use a centralized workflow
> as with CVS then yes, 90% cases you want to push the current branch. On
> the other hand, if people push their changes to the server only for
> review, it means that accidentally pushing more than one intended is not
> a big deal.
Perhaps not, but it was still unintended. I really can't understand the
opposition to making this command make many people less angry at it.
> The only one who does publishing to the official repository
> is the maintainer, and the maintainer is most likely to run some tests
> after merging all changes, which takes some time. So, it is rarely push
> the current branch, it is usually the branch that has been tested, so
> the name of the branch should be specified explicitly anyway.
Why is that relevant? That person can still use the explicit version of
the command.
Sam.
next prev parent reply other threads:[~2008-11-04 18:12 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20081030002239.D453B21D14E@mail.utsl.gen.nz>
2008-10-31 0:31 ` [PATCH] Documentation: add a planning document for the next CLI revamp Jeff King
2008-10-31 6:40 ` Sam Vilain
2008-10-31 8:20 ` Pierre Habouzit
2008-11-02 4:18 ` Jeff King
2008-11-02 9:56 ` Theodore Tso
2008-10-31 16:46 ` Johannes Schindelin
2008-11-02 3:42 ` Jeff King
2008-11-02 3:53 ` Jeff King
2008-11-02 22:27 ` Junio C Hamano
2008-11-03 5:59 ` Sam Vilain
2008-11-03 9:48 ` Jakub Narebski
2008-11-03 9:53 ` Sverre Rabbelier
2008-11-04 9:18 ` Dmitry Potapov
2008-11-04 18:10 ` Sam Vilain [this message]
2008-11-04 19:46 ` Junio C Hamano
2008-11-05 3:05 ` Jeff King
2008-11-05 6:40 ` Junio C Hamano
2008-11-05 22:53 ` Dmitry Potapov
2008-11-03 6:56 ` Jeff King
2008-11-03 6:59 ` Jeff King
2008-11-03 9:25 ` Pierre Habouzit
2008-11-03 23:33 ` Junio C Hamano
2008-11-04 0:02 ` Pierre Habouzit
2008-11-04 0:44 ` Junio C Hamano
2008-11-04 5:20 ` Jeff King
2008-10-30 3:48 Sam Vilain
2008-10-30 10:55 ` Stefan Karpinski
2008-10-31 11:38 ` Kyle Moffett
2008-10-30 13:24 ` Pierre Habouzit
2008-10-30 15:25 ` Julian Phillips
2008-10-31 0:34 ` Jeff King
2008-11-02 21:53 ` Junio C Hamano
2008-11-03 13:47 ` Pierre Habouzit
2008-10-30 14:34 ` Nicolas Pitre
2008-10-30 14:52 ` Shawn O. Pearce
2008-10-30 14:59 ` Mike Hommey
2008-10-30 15:01 ` Pierre Habouzit
2008-10-30 16:53 ` Nicolas Pitre
2008-10-30 17:31 ` Sam Vilain
2008-10-30 18:28 ` Nicolas Pitre
2008-10-30 22:46 ` Yann Dirson
2008-10-30 23:28 ` Sam Vilain
2008-10-30 23:55 ` Jakub Narebski
2008-10-31 6:51 ` Sam Vilain
2008-10-31 7:36 ` Jakub Narebski
2008-11-03 8:43 ` Sam Vilain
2008-11-03 12:06 ` Jakub Narebski
2008-11-01 0:37 ` Johannes Schindelin
2008-10-30 14:39 ` Theodore Tso
2008-10-30 14:43 ` Pierre Habouzit
2008-10-30 16:30 ` Theodore Tso
2008-10-30 16:43 ` Pierre Habouzit
2008-10-30 17:44 ` Sam Vilain
2008-10-30 17:03 ` Nicolas Pitre
2008-11-02 6:08 ` Junio C Hamano
2008-11-02 10:09 ` Theodore Tso
2008-10-30 15:02 ` Andreas Ericsson
2008-11-01 19:57 ` Elijah Newren
2008-10-30 15:20 ` Matthieu Moy
2008-10-30 17:00 ` Nicolas Pitre
2008-10-30 17:03 ` Pierre Habouzit
2008-10-30 17:17 ` Nicolas Pitre
2008-10-30 18:06 ` Sam Vilain
2008-11-02 22:17 ` Junio C Hamano
2008-11-03 6:01 ` Sam Vilain
2008-11-01 19:42 ` Elijah Newren
2008-10-30 17:51 ` Sam Vilain
2008-10-30 23:27 ` Theodore Tso
2008-11-01 20:27 ` Elijah Newren
2008-11-02 1:06 ` Theodore Tso
2008-11-02 4:41 ` Elijah Newren
2008-11-01 19:26 ` Elijah Newren
2008-11-02 22:01 ` Junio C Hamano
2008-11-01 18:36 ` Elijah Newren
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=1225822231.6722.3.camel@maia.lan \
--to=sam@vilain.net \
--cc=chriscool@tuxfamily.org \
--cc=dpotapov@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=kai@samba.org \
--cc=peff@peff.net \
--cc=samv@vilain.net \
--cc=schacon@gmail.com \
--cc=tom@github.com \
--cc=warthog19@eaglescrag.net \
/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).