On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:
> Unless you set @{u} to this new configuration, in which case the
> choice becomes dynamic depending on the current branch, but
>
> - if that is the only sane choice based on the current branch, why
> not use that as the default without having to set the
> configuration?
>
> - Or if that is still insufficient, don't we need branch.*.forkedFrom
> that is different from branch.*.merge, so that different branches
> you want to show "format-patch" output can have different
> reference points?
Yeah, I had similar thoughts. I personally use "branch.*.merge" as
"forkedFrom", and it seems like we are going that way anyway with things
like "git rebase" and "git merge" defaulting to upstream. But then there
is "git push -u" and "push.default = upstream", which treats the
upstream config as something else entirely.
So it seems like there is already some confusion, and either way we go,
thisis making it worse to some degree (I do not blame Ram, but rather he
has stumbled into a hidden sand pit that we have been building for the
past few years... :).
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.
-Peff
--
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