Re: [PATCH 2/2] format-patch: introduce format.defaultTo

Jeff King [off-list ref] writes:

On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:

quoted

quoted

I wonder if it is too late to try to clarify this dual usage. It kind of
seems like the push config is "this is the place I publish to". Which,
in many workflows, just so happens to be the exact same as the place you
forked from. Could we introduce a new branch.*.pushupstream variable
that falls back to branch.*.merge? Or is that just throwing more fuel on
the fire (more sand in the pit in my analogy, I guess).

I admit I haven't thought it through yet, though. And even if it does
work, it may throw a slight monkey wrench in the proposed push.default
transition.

Yeah, when I say "upstream", I never mean it as "where I publish".
Your upstream is where you get others' work from.

That's my thinking, as well, but it means the "upstream" push.default is
nonsensical. I've thought that all along, but it seems like other people
find it useful. I guess because they are in a non-triangular,
non-feature-branch setup (I suppose you could think of a central-repo
feature-branch workflow as a special form of triangular setup, where
the remote is bi-directional, but the branch names are triangular).

If we want to declare "push -u" and "push.default=upstream" as
tools for certain simple bi-directional workflows, that makes
sense.  But I suspect it may cause extra confusion when people
make the jump to using a triangular workflow.

I do not think there is no "want to declare" involved.  If I
correctly recall how "push -u" came about, it was merely a way to
appease those who complained that their new branch created by
running "checkout -b branch origin/branch" has already set up the
branch.*.remote and branch.*.merge configurations nicely for them
and allow them to immediately go ahead and start using the
centralized "I merge from their 'branch' and push to that", but when
they create a new branch on their own and want to make the branch of
the same name at the origin to be the "upstream", they have to futz
with the configuration.  The declaration was made long time ago when
we started using @{upstream}, and there is no new extra confusion.

quoted

For a "push to somewhere for safekeeping or other people to look at"
triangular workflow, it does not make any sense to treat that "I
publish there" place as an upstream (hence having branch.*.remote
pointing at that publishing point).

You _might_ treat it the same way we treat the upstream, in some special
cases. For example, when you say "git status", it is useful to see how
your topic and the upstream have progressed (i.e., do I need to pull
from upstream?). But you may _also_ want to know how your local branch
differs from its pushed counterpart (i.e., do I have unsaved commits
here that I want to push up?).

Correct; I am not saying "where do I publish" is never relevant.  It
is just it is not something useful for "format-patch" to use as the
default fork-point.

So having two config options might help with that. Of course, your "push
upstream" (or whatever you want to call it) does not logically have one
value. You may push to several places, and would want to compare to
each.

Yes.  But most likely, if you always push a single branch to
multiple places, it won't be like you push it to only one of the
places today and another one tomorrow, leaving everybody out of
sync.  Unless there is a site that is temporarily down, in which
case that one may stay behind, the normal state would be that all of
them point at the same commit (that is how I publish to multiple
places anyway).

quoted

Once you stop doing that, and
instead using branch.*.remote = origin, and branch.*.merge = master,
where 'origin' is not your publishing point, @{u} will again start
making sense, I think.

And I thought that is what setting "remote.pushdefault" to the
publishing point repository was about.

If that were sufficient, then we would just need "push.default =
current", and not "upstream" (nor "simple"). I lobbied for that during
the discussion, but people seemed to think that "upstream" was
better/more useful. Maybe it was just because remote.pushdefault did not
exist then.

Yeah, I think in the 2.0 world with pushdefault (i.e. triangular),
the default 'simple' turns into 'current'.