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
