Re: Git for Windows v2.20.0-rc0, was Re: [ANNOUNCE] Git v2.20.0-rc0

From: Bryan Turner <bturner@atlassian.com>
Date: Nov 20, 2018, 23:17 UTC
Message-ID: <CAGyf7-FALWBEfcu4OOsrQEKZJ=ub0=exM_f-Y7=avPqiwOeH7Q@mail.gmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.1811202152290.41@tvgsbejvaqbjf.bet>

On Tue, Nov 20, 2018 at 12:57 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 12 quoted lines

>
> Team,
>
> On Sun, 18 Nov 2018, Junio C Hamano wrote:
>
> > An early preview release Git v2.20.0-rc0 is now available for
> > testing at the usual places.  It is comprised of 887 non-merge
> > commits since v2.19.0, contributed by 71 people, 23 of which are
> > new faces.
>
> The "for Windows" flavor of Git v2.20.0-rc0 is available here:
>

Thanks again for publishing these release candidates! I greatly appreciate the effort that's involved, and the opportunity it affords to test new versions prior to their final release.

I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on both Linux and Windows, and the only failures were related to this change:

* "git branch -l <foo>" used to be a way to ask a reflog to be
   created while creating a new branch, but that is no longer the
   case.  It is a short-hand for "git branch --list <foo>" now.

Since this is an intentional change I suspect there's nothing to do for it but patch Bitbucket Server and move on, but I'll confess it's a little frustrating that the option was deprecated in 2.19 and then immediately removed in the next minor release. Such a backwards-incompatible change seems far more apt for a major release, a perspective that's reinforced by having the change follow such a brief deprecation period--2.19.0 was only tagged September 10th (in my timezone), so it's been less than 3 months. (Looking at the git branch documentation for 2.18.0 [1] shows nothing about this deprecation; the messaging first appears in 2.19.0 [2]. To be honest, I didn't even realize it was deprecated until now, when it's gone--our test suite is automated, so the deprecation warning was not visible.)

For what it's worth, I think having -l mean --list is a _good change_, and one that will likely be more natural for both new and existing users. It's the rapid changeover that hurts.

Best regards, Bryan Turner

[1] https://git-scm.com/docs/git-branch/2.18.0 [2] https://git-scm.com/docs/git-branch/2.19.0