On Fri, Mar 30, 2012 at 02:28:31PM -0700, Junio C Hamano wrote:
> 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.
OK, I can agree with that (although I can come up with some corner
cases, like a long-running branch that gets updates from master but is
never intended to be merged back in, I think we can safely say those are
advanced issues and not likely to be a problem for new git users).
So let's assume that you eventually plan for "topic" to go back into
"master", and focus on a more concrete issue: _when_ to merge. You fork
a topic branch from origin/master and make some commits. You then run
"git push". Did you mean:
1. I am ready for this work to go back to origin/master.
2. I am ready to publish my topic branch for others to review.
I think it's ambiguous. And getting it wrong is potentially hard to
retract (because you've published commits to what is probably supposed
to be a stable, non-rewinding branch).
> > 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.
I tend to think "upstream" is hopelessly blurry, and must remain so
because there are too many similar concepts. That is, to fix it, you
would need to split it into several sub-concepts.
For example, I generally base all of my git.git topics on origin/master
(where "origin" is your repo). But when I push them, they go to my
publishing point. So there are two things I am interested in asking
about:
1. Where is my work compared to master? This is useful for enumerating
which commits are part of my topic, and for rebasing on top of
master.
2. What do my local branches have compared to their published
versions? This is useful for knowing that I have work to be
published, or for realizing that I published work from another
machine that does not exist on the current machine.
Those are two very different notions of upstream, and I want to use them
with different commands. I set @{u} to origin/master to handle (1). And
I do (2) by matching names. But I would never want git-push to look at
@{u}, because it is a totally different concept. Pushing is always about
(2) for me.
Yes, this is a more complex workflow than many beginning git users will
have. But I think it is at the heart of the upstream confusion: just
because you are based on some branch, and just because you ultimately
want to merge with it, does not mean that it is a good push destination.
_Sometimes_ it is, and that is why the "upstream" push.default exists.
> 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?
Yes, and we should make upstream better, no matter what the default is.
But I hoped that it would not be "blindly teach" but rather "teach what
upstream is". Perhaps that is naive. But I feel like at least we will
have done the best we can by giving the user an opportunity to read the
documentation or have somebody instruct them before setting "upstream",
and not simply shipping it out of the box.
-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