Pierre Habouzit <madcoder@debian.org> writes:
quoted text
>   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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html