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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 21, 2018 at 6:20 AM Jeff King <peff@xxxxxxxx> wrote:
>
> On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
>
> > 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.)
>
> We did go a bit faster than usual, under the assumption that nobody's
> really using "-l". It has been the default since 2006.
>
> Can you tell us a little more about your invocation?

Our invocation is... A little difficult to nail down, if I'm honest.
Bitbucket Server code does not use "git branch -l" anywhere in its
_shipping_ code, only in its _test_ code.

But that test code exists because Bitbucket Server provides a Java API
[1][2] which allows third-party developers to easily build arbitrary
Git commands to invoke for their own functionality. Setting
`GitBranchCreateBuilder.reflog(true)` will trigger adding "-l" to the
assembled "git branch" command. I've changed the code now so that it
will use "--create-reflog" instead; however, because many of the
Bitbucket Server add-ons on Marketplace [3], whether free or paid, are
not open source, and because there are a significant number of
in-house plugins that are not listed there, it's difficult to know how
many might be affected. If I were to hazard a guess it would be
_none_, but I've been surprised before. The end result is that the net
impact is hard to predict--especially because Git on the server would
need to be upgraded to 2.20.

(In case you're curious why we used shorthand options, it's because of
our Windows support. While "git branch" commands rarely, if ever, get
very long, as a general rule we use shorthand options where they exist
to keep our command lines shorter, to allow passing more options
without hitting the hard limit (generally 32K) imposed by
Windows--something we _have_ had issues with on other commands. For
commands like "git diff", where it's not possible to pass in paths via
stdin, every character matters.)

To try and protect against the unexpected, we have a Supported
Platforms [4] page which lists Git versions that we've _explicitly
tested_ with Bitbucket Server. 2.20 won't be marked tested until a
future release, so the majority of installs will not use it with older
versions of the system--but there's always that subset who ignore the
documentation. (Since we do text parsing on Git output, subtle
breakages do happen from time to time.)

I would say it's _unlikely_ that we'll hear of any installations where
all the conditions are met for this to come up:
- Git 2.20
- Bitbucket Server (without fixes)
- Third-party add-on using `reflog(true)`

It's really just that a) I was caught off guard by the change (my own
fault for not reading the 2.19 announcement more carefully) and b)
it's impossible for me to say with _certainty_ that it won't be an
issue. I'd imagine that latter point is true of the change in general,
though (it's not really possible to know what scripts it might break,
and that's going to be true regardless of when the change actually
gets released), and I'd agree that that shouldn't hold Git back from
making useful improvements.

Thanks for your time!

Bryan

[1] https://docs.atlassian.com/bitbucket-server/javadoc/5.16.0/git-api/reference/com/atlassian/bitbucket/scm/git/command/GitScmCommandBuilder.html
[2] https://docs.atlassian.com/bitbucket-server/javadoc/5.16.0/git-api/reference/com/atlassian/bitbucket/scm/git/command/branch/GitBranchCreateBuilder.html
[3] https://marketplace.atlassian.com/addons/app/bitbucket
[4] https://confluence.atlassian.com/bitbucketserver/supported-platforms-776640981.html#Supportedplatforms-dvcsDVCS

>
> We still have time to avoid the change for this release. And this early
> testing of master and release candidates is wonderful exactly to get
> this kind of feedback before it's too late.
>
> -Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux