Re: [ANNOUNCE] Git 1.7.10-rc3

From: Jeff King <peff@peff.net>
Date: Mar 29, 2012, 22:11 UTC
Message-ID: <20120329221154.GA1413@sigill.intra.peff.net>
In-Reply-To: <7vbonfqezs.fsf@alter.siamese.dyndns.org>

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

Show 5 quoted lines

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

Show 11 quoted lines

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

Show 8 quoted lines

> 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