Re: git push (mis ?)behavior

From: Miles Bader <miles.bader@necel.com>
Date: Oct 3, 2007, 08:57 UTC
Message-ID: <buobqbgmv6z.fsf@dhapc248.dev.necel.com>
In-Reply-To: <20071003073554.GA8110@artemis.corp>

Pierre Habouzit <madcoder@debian.org> writes:

Show 5 quoted lines

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

Even if the default were changed, it could very well end up causing many problems because it _didn't_ push as many heads as the user thought it would (I don't think I'm the only one that might expect the default action to be "push everything"). When I was a git newbie, I sometimes got into situations where I screwed something up because heads I thought had been pushed to another system actually hadn't been.

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.

-Miles

-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.