On Tue, Jan 07, 2014 at 03:40:56AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > 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.
>
> My issue with that is that I no idea where my branch is with respect
> to my forked upstream; I find that extremely useful when doing
> re-spins.
Right. I think there are two separate relationships, and they are both
shoe-horned into "upstream". The solution is to let them be configured
separately (and fallback on each other as appropriate to make the burden
less on the user).
> push.default = upstream is a bit of a disaster, in my opinion. I've
> advocated push.default = current on multiple occasions, and wrote the
> initial remote.pushDefault series with that configuration in mind.
Yeah, I agree with all of that.
> > 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).
>
> We already have a branch.*.pushremote, and I don't see the value of
> branch.*.pushbranch (what you're referring to as pushupstream, I
> assume) except for Gerrit users.
Yes, "pushbranch" is probably a better name for what I am referring to.
I agree that pushremote is probably enough for sane cases. I seem to
recall that people advocating the "upstream" push-default thought that
branch name mapping was a useful feature, but I might be
mis-remembering. I will let those people speak up for the feature if
they see fit; it seems somewhat crazy to me.
> Frankly, I don't use full triangular workflows myself mainly because
> my prompt is compromised: when I have a branch.*.remote different from
> branch.*.pushremote, I'd like to see where my branch is with respect
> to @{u} and @{publish} (not yet invented);
Yes, as two separate relationships, you would theoretically want to be
able to see them separately (or simultaneously side by side). Whether
exposing that in the prompt is too clunky, I don't know (I don't even
show ahead/behind in my prompt, but rather prefer to query it when I
care; I have a separate script that queries the ahead/behind against my
publishing point, but it would be nice if git handled this itself).
> > 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.
>
> We're transitioning to push.default = simple which is even simpler
> than current.
Simpler in the sense that it is less likely to do something unexpected.
But the rules are actually more complicated. Two examples:
1. Imagine I make a feature branch "foo" forked off of origin/master, then
"git push" with no arguments. The "current" scheme would go to
"foo" on origin, but "upstream" would go to "master". Since they
don't agree, "simple" will punt and tell me to be more specific.
2. Imagine I have set my default push remote to "publish", am on
master (forked from "origin/master") and I run "git push" without
arguments. "current" would push to "master" on "publish". But
"upstream" will complain, because we are not pushing to our
upstream remote. I believe "simple" will therefore reject this.
In both cases, I think "current" does the sane thing, and "simple" makes
things more complicated. The one saving grace it has is that it punts on
these cases rather than potentially doing something destructive that the
user did not intend.
-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