Ramkumar Ramachandra <artag...@gmail.com> writes:
> Currently, there is no way to invoke 'git push' without explicitly
> specifying the destination to push to as the first argument. When
> pushing several branches, this information is often available in
> branch.<name>.pushremote, falling back to branch.<name>.remote. So,
> we can use this information to create a more pleasant push experience.
> You can now do:
> $ git push master next pu
> If the branches master, next, and pu have different remotes, do_push()
> will be executed three times on the three different remotes.
I am lukewarm on this one, slightly more close to negative than
positive, for a couple of reasons.
The primary reason is the confusion factor Jeff mentioned in the
thread that inspired this patch. People would realize it is very
natural to decide where to push to based on what branch is being
pushed, but only after they think it long and hard enough [*1*]. I
suspect that it is an equally natural expectation for casual users
that the destination is chosen based on the current branch, if only
because that is what they are used to seeing when they say "git
push" without any argument.
Even though I personally am in favor of this "destination is tied to
what is pushed out", not "destination is chosen based on the current
branch", I can understand why some people would prefer the latter,
and why they find it simpler and easier to explain.
The second reason is purely on the differences between what the
above clean-nice explanation says and what the patch actually does.
I think "is-possible-refspec" and "pushremote-get-for-refspec" are
both way over-engineered, even for people who agree with me and the
above introduction for this change to favor "destination depends on
what branch is pushed out". If is-possible-refspec is replaced with
a much simpler to understand logic, "Is this a local branch name?",
possibly combined with "There is no such path on the filesystem" and
"It's not a defined remote" (iow, reject "git push master:next" and
anything more complex) [*2*], I suspect it would be a bit more
*1* I've explained in a separate message why basing the destination
on what is being pushed is logical and internally consistent.
*2* This is in the same spirit (not implementation or design) as
revname vs pathspec disambiguation.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html