Re: push.default: current vs upstream

From: Jeff King <peff@peff.net>
Date: Mar 30, 2012, 21:53 UTC
Message-ID: <20120330215344.GD20734@sigill.intra.peff.net>
In-Reply-To: <7vzkaxkccg.fsf@alter.siamese.dyndns.org>

On Fri, Mar 30, 2012 at 02:28:31PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> 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).

Show 6 quoted lines

> > 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.

Show 7 quoted lines

> 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