Jeff King <peff@xxxxxxxx> writes:
> On Fri, Mar 30, 2012 at 01:25:03PM -0700, Junio C Hamano wrote:
>
>> And the reason why it is surprising to the beginners is? Because "topic"
>> and "master" (of "origin/master") are not the same name?
>
> Sort of. It is more because "upstream" is an overloaded concept. Perhaps
> you created the branch from origin/master because you wanted to say
> "this is where my topic is based, and when I 'rebase -i' later, I want
> it to be considered the baseline". Or perhaps you meant to say "I am
> going to work on origin's master branch, but I would prefer to call it
> 'topic' here".
In either case, you seem to be assuming (and it is a correct assumption,
even though we may not use such a workflow) that the resulting branch, if
long lived, will be rebasing on top of origin/master. And the reason why
you do that is because...
Because you would eventually want to get it integrated into origin's
master. Otherwise you can stay apart from origin/master and keep your
foundation solidly anchored to where you started.
So in that sense, in both cases, pushing back to origin/master is likely
to be what the user expected in the first place.
Like it or not, many parts of Git that is "upstream"-aware have been over
time taught to make it easier for the eventual result easier to be pushed
back to the "upstream" at the remote, I think. "log --left-right @{u}..."
will show what you and others have done, "rebase" knows to use @{u} when
figuring out on which commit to rebuild your current branch, etc.
> So we have to decide when two things are forks of "the same branch", and
> when it is merely "X is based on Y", or "X happens to have the same name
> as Y". And I think the "name is the same" semantics are way more
> obvious.
I obviously agree with that.
>> I tend to think that this is on the "understandable" side of the line
>> (after all, I said "Let's start a topic to be merged to origin/master"
>> when I started the topic, and I've been rebasing the topic up to date from
>> time to time), but obviously you don't think so.
>
> Is that what you said? Or did you say "I am starting a new topic that
> will be based on origin/master?"
See above ;-) Having said that...
> I feel like the concept of "upstream"
> is very loosely specified, and can mean many things.
...I tend to agree with it. But I am not sure if that leads to "we should
default to 'current' because 'upstream' is too messy and blurry". At
least, not yet.
> Ultimately, it is not about whether one workflow is better than the
> other. It is about having a default that stops the user and says "hey, I
> don't know what workflow you're using. So you need to tell me before I
> can continue."
OK. Obviously we would not want to default to 'push.default = nothing',
and 'current' is far simpler to explain.
But then I am afraid that you may be inviting teachers to blindly teach
beginners to first set push.default to upstream, just like they do today
where the default is matching, as most of them do know that upstream works
fairly well with the way how _they_ work, without having an understanding
these gotchas in upstream you are (validly) raising as possible issues
here. So in the end, we would have to clarify whatever 'upstream' does
anyway, no?
--
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