Re: [ANNOUNCE] Git 1.7.10-rc3

[Jeff King <peff@peff.net>]

On Thu, Mar 29, 2012 at 02:22:31PM -0700, Junio C Hamano wrote:

> > Did we decide that "upstream" will be the new rule in future versions? I
> > still have some misgivings about that (versus "current"), but I thought
> > the only decision we were settling now was whether to change at all.
> 
> I counted the AOL me-too on "upstream" vs "current" ;-)

I did, too, but as you are so fond of reminding us, this is not a
democracy. :)

> Seriously speaking, I think we have enough time to make sure that
> "upstream" errors out with an appropriate advice when:
> 
>  - The user says "git push" (no remote, no refspec) on a branch without
>    any tracking set; or
> 
>  - The user says "git push $remote" (either remote nick or url, no
>    refspec) when there is no "remote.$remote.push" and the current branch
>    does not have tracking set to that remote (includes the cases where it
>    does not have any tracking set, and where it has tracking set to
>    different remote).

Right. This was one of my two concerns: many upstream corner cases do not
currently make sense, and before we switch to it as a default, those
bugs need to be dealt with. And I think that refusing to push in those
cases is the right thing.

But I would withhold a decision on "upstream" versus "current" until
those bugs are ironed out, because what people think of as "upstream"
(today's current behavior)  may not be exactly what it ends up as.
In particular, the common beginner workflow of:

  $ git clone ...
  $ git checkout -b topic
  $ hack hack hack
  $ git push

would error out (whereas with "current", it would do something
reasonably sane and predictable). The "upstream" push default relies on
the upstream config being set up in a sane way, but in my experience,
that does not always happen in every workflow.

> The "easy to understand for beginners" explanation for "upstream" becomes:
> 
>   Nothing is pushed until you explicitly say what is pushed where, and you
>   can say that by either:
> 
>    - setting remote.$remote.push;
>    - setting branch.$current.merge; or
>    - saying it on the command line.

Or "git has set up branch.$current.merge for you already". The second of
my two concerns is that this:

  $ git clone ...
  $ git checkout -b topic origin/master
  $ hack hack hack
  $ git push

will try to implicitly fast-forward merge your commits onto master. Some
people have said they really like that behavior, but I think it can be a
bit surprising for beginners.

Anyway, I didn't exactly want to re-open the upstream versus current
debate at this point (and actually, I think a hybrid "do nothing unless
upstream and current would agree on the behavior, and give copious
advice" approach might be the best thing). I just wanted to make sure
things were still open for consideration, and was concerned that we are
creating false expectations by putting "upstream" into the release
notes.

-Peff