On Nov 22, 2007, at 12:23 PM, Johannes Schindelin wrote:
I have to say that I slowly grow an antipathy for "git push" without
parameters. _All_ of the confusions with push that I saw stem from
being
too lazy to say where and what you want to push. (Okay, there is this
other thing where people say "git push origin master:master" and I
still
do not know where they got _that_ from.)
I don't agree. "git push" should support good defaults. At
some point you make the decision to publish, and you use
"git push" for this. If you have a reasonably stable environment
there will be a good default, what publishing means.
Obviously users should think before they "git push". They know
that they are publishing, and they (hopefully) understand
that they can't easily undo this operation. But I believe
people who used any version control system before know that.
It's the same for every system. If you publish, others can
get your source, and this can't easily be reverted.
But people are lazy, and having a good default is what they
expect from a good tool. The default should be safe, and
reliably do something useful. A good default can safe you
from typing errors. But the default should not do too much,
and should not do unexpected things; at least not until you
explicitly configured.
You know that I believe the current default is not such a
choice. Pushing matching branches sooner or later triggers
annoying errors if used with a shared remote repository.
But this is how the default is; and I'll live with it.
At least it saves me time. I learnt to ignore the error
messages. And we now have '--dry-run'. So I can quickly
check what will happen.
But, I strongly believe that a tool that expects users to
type the current branch and the default remote each time;
just for publishing some changes to the default location,
is not what users want.
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
