All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: Miles Bader <miles@gnu.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: git push (mis ?)behavior
Date: Wed, 03 Oct 2007 11:03:32 +0200	[thread overview]
Message-ID: <20071003090332.GC12042@artemis.corp> (raw)
In-Reply-To: <buobqbgmv6z.fsf@dhapc248.dev.necel.com>

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

On Wed, Oct 03, 2007 at 08:57:56AM +0000, Miles Bader wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> >   There definitely is a point: with the current behaviour you sometimes
> > end up pushing more than what you meant, with sometimes WIP that you
> > intend to rebase, and it hurts. Git porcelains should help you avoid to
> > shoot yourself in the foot, hence I think that (especially to git
> > newcomers), the current default _is_ dangerous.
> 
> What's "dangerous" for newbies, often ends up being what doesn't
> correspond with their mental model.  I think the current default
> behavior without any <refspec> specified corresponds well to the
> operation of many other git commands (and unix command) in similar
> circumstances:  If you don't specify something to operate on, it
> essentially uses a wild card and operates on "every reasonable thing"
> (e.g., consider "git commit FILE" versus "git commit").

  Git commit is hardly a wildcard as it only operates on what you put in
your index, which is hardly something that happens behind your back.

> To the extent that a command _is_ "dangerous", there's always a tradeoff
> between convenience and "danger".  Some systems (e.g. those aimed at
> newbies) might have as a goal to do the absolute minimum with every
> command and always, always, err on the side of safety.  I don't think git
> is that system.

  I beg to differ then. I believe that "git push" default behavior is
wrong. I'm not really a newbie, and it often did not do what I meant. So
it could also be that there isn't a sane default either. I just say the
current one can lead to gross mistakes.

  I know that some porcelains are risky: if you rebase "under" a point
that was published you are shooting yourself in the foot e.g.. But
git-rebase _is_ a command that rewrites history. You're warned from the
first second you use it. But git-push is supposedly only a transport
command, not something that messes with remotes history behind your
back.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-10-03  9:03 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-27 13:04 git push (mis ?)behavior Pierre Habouzit
2007-09-27 13:30 ` Wincent Colaiuta
2007-09-27 15:28   ` Benoit SIGOURE
2007-09-27 19:22 ` Junio C Hamano
2007-09-27 19:36   ` Pierre Habouzit
2007-09-28  6:52   ` Steffen Prohaska
2007-09-28  6:58     ` Pierre Habouzit
2007-09-28  9:26       ` Steffen Prohaska
2007-09-28  9:44         ` Junio C Hamano
2007-09-28 10:04           ` Steffen Prohaska
2007-09-28  7:07     ` Junio C Hamano
2007-09-28  9:11       ` Steffen Prohaska
2007-09-28 13:31         ` Johannes Schindelin
2007-10-09  5:05       ` Jan Hudec
2007-10-09  7:23         ` Steffen Prohaska
2007-09-28 12:38   ` Wincent Colaiuta
2007-10-03  5:10   ` Miles Bader
2007-10-03  5:39     ` Junio C Hamano
2007-10-03  6:47     ` Wincent Colaiuta
2007-10-03  8:32       ` Miles Bader
2007-10-03  7:35     ` Pierre Habouzit
2007-10-03  8:57       ` Miles Bader
2007-10-03  9:03         ` Pierre Habouzit [this message]
2007-10-03 10:25         ` Wincent Colaiuta
2007-10-03 10:49           ` Karl Hasselström
2007-10-03 11:08             ` Junio C Hamano
2007-10-03 11:22               ` Wincent Colaiuta
2007-10-03 13:14               ` Karl Hasselström
2007-10-03 15:27             ` Johannes Schindelin
2007-10-03 16:07               ` Karl Hasselström
2007-10-03 16:18                 ` Johannes Schindelin
2007-10-03 16:28                   ` Pierre Habouzit
2007-10-03 16:44                     ` Johannes Schindelin
2007-10-03 17:02                       ` Karl Hasselström
2007-10-04 14:47                         ` Steffen Prohaska
2007-10-04 15:54                           ` Wincent Colaiuta
2007-10-04 16:24                             ` Steffen Prohaska
2007-10-04 17:49                               ` Wincent Colaiuta
2007-10-03 16:26               ` Wincent Colaiuta
2007-10-03 11:10           ` Benoit SIGOURE

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=20071003090332.GC12042@artemis.corp \
    --to=madcoder@debian.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=miles@gnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.