git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Wincent Colaiuta <win@wincent.com>
To: Miles Bader <miles@gnu.org>
Cc: Pierre Habouzit <madcoder@debian.org>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: git push (mis ?)behavior
Date: Wed, 3 Oct 2007 12:25:22 +0200	[thread overview]
Message-ID: <83C5420A-528A-43F0-AF8C-699B85B7AD95@wincent.com> (raw)
In-Reply-To: <buobqbgmv6z.fsf@dhapc248.dev.necel.com>

El 3/10/2007, a las 10:57, Miles Bader escribió:

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

While much of this debate can be shortcircuited simply by making the  
behaviour configurable, I would like to take you up on the point that  
you raise here.

If we're going to talk about what kind of system Git is then consider  
this:

- it's inherently distributed and this design actively encourages  
users to treat their local repositories as sandboxes where things are  
tried out, perfected, and then pushed out into the public via one  
means or another

- it's built from the ground up to be good at branching and merging;  
this, combined with my previous point, means that users are likely to  
have multiple heads and often some of them will be "works in  
progress" that aren't yet ready for publication

So it's in that light I see accidentally pushing more than you  
thought you would as "dangerous"; when you make this mistake you're  
basically making stuff available that's not yet ready for  
consumption, and by its nature this mistake is basically  
irreversible: you can't really "unpush" what you pushed, you can only  
push out additional amendments which correct it.

So, in this light, when you say:

> What's "dangerous" for newbies, often ends up being what doesn't
> correspond with their mental model.

I don't know how much it has to do with mental models. I think in  
this case it's a bit simpler than that where you make the mistake  
once or twice and very quickly learn that "git push" means "push  
what's in my repo", not "push only what's on my current branch". It's  
a *very* easy lesson to learn if you get burnt and hardly requires  
any adjustments to ones "mental model".

I personally would be in favour of changing the default because I  
tend to work on a particular branch at a time and then want to push  
*that* out -- generally I'm thinking about one general area or one  
task at a time, and that means one branch at a time; I almost never  
think along the lines of getting all my branches into shape at once  
and then pushing them out in a batch. I think this is more likely to  
be a common pattern, although obviously that remains speculation at  
this point.

Changing the default would be great for people like me; by not having  
to pass additional parameters to git-push I save some keystrokes. If  
I ever want to push everything an "--all" switch would do the job.  
But if people prefer to keep the old default then there'll  
be .gitconfig for people like me. In any case I think more people  
need to speak up on the topic so that we can find out what most  
people really think about changing the default.

Cheers,
Wincent

  parent reply	other threads:[~2007-10-03 10:25 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
2007-10-03 10:25         ` Wincent Colaiuta [this message]
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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83C5420A-528A-43F0-AF8C-699B85B7AD95@wincent.com \
    --to=win@wincent.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=madcoder@debian.org \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).