Re: Git for Windows v2.20.0-rc0, was Re: [ANNOUNCE] Git v2.20.0-rc0
On Wed, Nov 21, 2018 at 11:28:28AM -0800, Bryan Turner wrote: > 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. Yeah, that is slightly worrisome. In some sense we can guess that calling ".reflog(true)" is in the same league as our assumption of "probably nobody is using -l in the first place", but it's one more place that might have encouraged people into using it, even if it's a noop. > (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.) I follow your reasoning, though that is not the engineering decision I would have made. The long-names tend to be more robust, and while saving a few bytes might make a case work that would not otherwise, it is really only delaying the inevitable. But hey, it's not my product. ;) We probably should support --stdin in more places to cover situations like this. Patches, welcome. Also, I have noticed that performance with a large number of pathspecs tends to be pretty poor, as we search them linearly. I wonder if you've run into that, too (or maybe, coming from a Java world, you simply have a small number of extremely long path names ;) ). A while ago I experimented with putting non-wildcard pathspecs into a trie structure that we could traverse while walking the actual trees to diff. I never really polished it because having a huge number of pathspecs didn't seem like a common use case. > 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)` Thanks for laying this out (and again, thanks for testing and reporting this before the release!). I'm comfortable with continuing with the change in v2.20 at this point, but I'm also totally fine with bumping it for another release. Your case is about Bitbucket, but there may well be other scripts in the wild. > 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. The advantage of bumping is that if you switch Bitbucket to "--create-reflog" _now_, it's more likely to be deployed by the time the Git change comes. In theory that also helps people who may not have upgraded to v2.19 yet, but I suspect in many cases people don't notice the warning at all (because it's buried in some script output) and will only notice once the breaking change ships. Then the deprecation period only gives us a larger ability to say "I told you so...", but that is small satisfaction to the person whose script was broken. -Peff
Re: Git for Windows v2.20.0-rc0, was Re: [ANNOUNCE] Git v2.20.0-rc0
On Wed, Nov 21, 2018 at 6:20 AM Jeff King 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 " 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 " 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
Re: Git for Windows v2.20.0-rc0, was Re: [ANNOUNCE] Git v2.20.0-rc0
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 " 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 " 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? 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
Re: Git for Windows v2.20.0-rc0, was Re: [ANNOUNCE] Git v2.20.0-rc0
On Tue, Nov 20, 2018 at 12:57 PM Johannes Schindelin wrote: > > 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 " 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 " 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
Git for Windows v2.20.0-rc0, was Re: [ANNOUNCE] Git v2.20.0-rc0
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: https://github.com/git-for-windows/git/releases/tag/v2.20.0-rc0.windows.1 The current change log for v2.20.0 reads like this: Changes since Git for Windows v2.19.1 (Oct 5th 2018) Please note: Git CMD is deprecated as of this Git for Windows version. The default is to have git.exe in the PATH anyway, so there is no noticeable difference between CMD and Git CMD. It is impossible to turn off CMD's behavior where it picks up any git.exe in the current directory, so let's discourage the use of Git CMD. Users who dislike Git Bash should switch to Powershell instead. New Features • Comes with OpenSSH v7.9p1. • The description of the editor option to choose Vim has been clarified to state that this unsets core.editor. • Comes with cURL v7.62.0. • The type of symlinks to create (directory or file) can now be specified via the .gitattributes. • The FSCache feature now uses a faster method to enumerate files, making e.g. git status faster in large repositories. • Comes with Git Credential Manager v1.18.3. • Comes with Git LFS v2.6.0. • Comes with MSYS2 runtime (Git for Windows flavor) based on Cygwin 2.11.2. • The FSCache feature was optimized to become faster. Bug Fixes • The 64-bit Portable Git no longer sets pack.packSizeLimit. Thanks, Johannes
