Jeff King [off-list ref] writes:
... This is not a push.default issue,
but I think it is somewhat related, and maybe worth discussing along
with the topic of asymmetry. ...
I've mostly trained my fingers to type "git push
<my-publish-repo>", but I do occasionally forget.
In an assymmetric set-up, you would typically push into one place
but update from one or more places, so it might make sense to make
it easier to say "git push" and "git pull $there". But that does
not solve the fundamental issue, I would think.
Do other people with
asymmetric workflows find this annoying? Do they not care? Or are many
fewer people doing asymmetric things than I think?
I think it is not "they do not care", but "they do not have a good
solution". I do not think of anything offhand, either.
While I'm ranting, there's another weirdness I noticed. If I have
push.default set to upstream, and config like this:
[branch "foo"]
remote = origin
merge = refs/heads/master
then typing "git push" will go to foo's master branch. But if I type
"git push other-remote", then it will go to other-remote's master
branch. Which makes no sense to me. The upstream is foo's master, and
now we are making guesses about how the names on each side are the same.
Is this an intentional behavior?
Because "upstream" is meant to be "For the branch I am on, you know
how the branches map between the remote repository, so you already
know what the right thing to do---do it" mode, the correct "guess"
in your case is to error out and say "Nah, you are not talking with
your upstream, so I do not have any clue what branches you want to
push out and how. As you said that the push.default is upstream, not
matching, I refuse to even do the matching push in your case. This
is an error. Be more specific".
Actually, this is the thing that scares me the most about "upstream" as
a default, because in this case, you are implicitly performing the
equivalent of a fast-forward merge. So that's handy if you are a new
user who wants to publish your work back to the master branch. But that
has two problems:
1. If you are a new user who does like the implicit merge, you
may find it convenient not to have to learn about ... << and we
shouldn't discourage them from learning as it will be needed
anyway >>
2. If you are a new user who _doesn't_ want to do the merge, but
instead wants to publish your work-in-progress topic, then the
implicit merge-back-to-master behavior is wrong and dangerous.
<< the newbie may push -f ruining the work of others >>
I agree with both points. Also there is a cross-variant issue of
the above two:
If a new user hears "not fast-forward, first pull and then
push again", that will be done on a topic branch, merging
'master' back and then pushing the result to 'master',
leaving the 'master' of the user behind.
So far a lot of the discussion has focused on "what is the most sensible
default for the most number of people". But I wonder if a better
question is "what is the default that is the least likely to do
something dangerous and embarrassing". People who use git enough to say
"wow, I don't like this default for my workflow" are probably at the
point that they can configure push.default themselves.
I do not think "the most number of people" is a high-priority issue,
but "least damage" default may not be necessarily the best.
Obviously, "nothing" is the least-damage option, and looking at how
even people on this list cannot decide between current and upstream,
I actually am very tempted to suggest it as the new default.
On 12-03-12 03:06 PM, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
So far a lot of the discussion has focused on "what is the most sensible
default for the most number of people". But I wonder if a better
question is "what is the default that is the least likely to do
something dangerous and embarrassing". People who use git enough to say
"wow, I don't like this default for my workflow" are probably at the
point that they can configure push.default themselves.
I do not think "the most number of people" is a high-priority issue,
but "least damage" default may not be necessarily the best.
I agree, but I don't think we even have a good idea of what "least damage"
even means. It seems to be vaguely related to how much of a hassle it would
be to recover from a plain "git push" doing the wrong thing.
There's one thing I'd like to ask all the folks who are pointing out how well
the candidate defaults match various workflows: How much training do you
give (or are assuming for) your workflow's new users?
Or, more broadly, what is a "new" git user? Are we talking about someone
using git for the first time on a brand-new project that they're setting up
themselves? (Has that person even used any other VCS's?)
Or is it someone who's joining an already-established team? Even a "new"
user hacking the Linux kernel or forking some github project is tying into an
established process. And most every established process has either
documentation (or a person) to explain how things are set up, and how to best
configure git to work in that environment.
IMHO git need not worry about "new" users joining an established process, if
for no other reason that it seems impossible to make git new-user-friendly in
all (or even most) of those environments.
Instead the focus should be on new users who are wrestling with git by
themselves (well, hopefully with the help whatever online documentation
they've found). They're making up their workflows as they go, refining them
as they learn more about git. These are the users that git's defaults should
cater to.
And for those users, I still think "upstream" is the best of the current
default candidates.
Obviously, "nothing" is the least-damage option, and looking at how
even people on this list cannot decide between current and upstream,
I actually am very tempted to suggest it as the new default.
There's a lot of merit to that. If nothing else, it'd get new users to learn
at least a little bit about git. I wouldn't be opposed to pushing nothing by
default.
M.
On Mon, Mar 12, 2012 at 12:06:48PM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
... This is not a push.default issue,
but I think it is somewhat related, and maybe worth discussing along
with the topic of asymmetry. ...
I've mostly trained my fingers to type "git push
<my-publish-repo>", but I do occasionally forget.
In an assymmetric set-up, you would typically push into one place
but update from one or more places, so it might make sense to make
it easier to say "git push" and "git pull $there". But that does
not solve the fundamental issue, I would think.
I think it can even be a bit more complex than that. For example, I
actually _never_ run git-pull. Instead, I fetch, and then use the
upstream config for lots of other operations, like seeing what's in a
topic branch, rebasing, etc.
So to me, it is not just about "symmetry between push and pull", but
that the upstream config is fundamentally about "what is this work based
off of", which may or may not have anything to do with where you are
pushing to.
quoted
Do other people with
asymmetric workflows find this annoying? Do they not care? Or are many
fewer people doing asymmetric things than I think?
I think it is not "they do not care", but "they do not have a good
solution". I do not think of anything offhand, either.
The branch.*.pushRemote you mentioned would help with that. But for me,
I would much rather have simply push.defaultRemote. Configuring each
branch independently would be a pain, and I always want to push to my
publishing point (or at least, by default; anything else is a one-off
that can get an option on the command line). It is not a per-branch
thing at all for me.
Speaking of which, I often get annoyed at the per-branch
auto-configuration of upstreams. For example, I find myself doing this:
[get an idea, read a bug report on the list, etc]
$ cd git
$ hack hack hack
[oh, this is turning into something real. Let's make a branch]
$ git checkout -b jk/bug-fix
$ git commit -m 'fix bug'
but now my bug-fix branch is based off of wherever I was (which is
usually some private topic-integration branch I run most of the time).
I wish there was some way to say "No, branches should _always_ consider
origin/master as their upstream, unless I configure them some other
way" (which I do occasionally for building sub-topics on other topics).
Which makes me wonder if perhaps people are using "upstream" to mean
several different thing. I use it to say "this is the branch that this
topic is based off of", which makes "git log @{u}.." helpful, "git
rebase -i" just work, and gives some meaning to the ahead/behind message
(it shows how my topic relates to the main project).
But I think people also use upstream to mean "this is the definitive
version of this branch in some central repo". So they would say that
"jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind
message is about "do I have any local work that needs pushed, or any
remote work that needs pulled?"
And I wonder if this is where some of the debate for
push.default=upstream comes from. Whether that is useful to you or not
would depend on how you set up your branches. In the latter model, I
would think pushing to the upstream would be the right thing.
Because "upstream" is meant to be "For the branch I am on, you know
how the branches map between the remote repository, so you already
know what the right thing to do---do it" mode, the correct "guess"
in your case is to error out and say "Nah, you are not talking with
your upstream, so I do not have any clue what branches you want to
push out and how. As you said that the push.default is upstream, not
matching, I refuse to even do the matching push in your case. This
is an error. Be more specific".
Yeah, I agree that is the only sane thing to do.
I do not think "the most number of people" is a high-priority issue,
but "least damage" default may not be necessarily the best.
Obviously, "nothing" is the least-damage option, and looking at how
even people on this list cannot decide between current and upstream,
I actually am very tempted to suggest it as the new default.
I was tempted to suggest that, but it somehow feels too overboard and
unfriendly. I really like "current", as it seems like the simplest and
unsurprising thing we can do, short of doing nothing at all.
-Peff