git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Bryan Turner <bturner@atlassian.com>
To: Jeff King <peff@peff.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>,
	Git Users <git@vger.kernel.org>,
	git-for-windows@googlegroups.com, git-packagers@googlegroups.com
Subject: Re: Git for Windows v2.20.0-rc0, was Re: [ANNOUNCE] Git v2.20.0-rc0
Date: Wed, 21 Nov 2018 11:28:28 -0800	[thread overview]
Message-ID: <CAGyf7-FDZxCTfXV_HwHRS3PiWnLR08F5B=whxAizOsjJFUCi+g@mail.gmail.com> (raw)
In-Reply-To: <20181121142026.GA10324@sigill.intra.peff.net>

On Wed, Nov 21, 2018 at 6:20 AM Jeff King <peff@peff.net> 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

  reply	other threads:[~2018-11-21 19:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-18 14:20 [ANNOUNCE] Git v2.20.0-rc0 Junio C Hamano
2018-11-20 20:56 ` Git for Windows v2.20.0-rc0, was " Johannes Schindelin
2018-11-20 23:17   ` Bryan Turner
2018-11-21 14:20     ` Jeff King
2018-11-21 19:28       ` Bryan Turner [this message]
2018-11-22 16:38         ` Jeff King
2018-11-22  8:01   ` Git for Windows v2.20.0-rc0 stefan.naewe
2018-11-22 17:25     ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGyf7-FDZxCTfXV_HwHRS3PiWnLR08F5B=whxAizOsjJFUCi+g@mail.gmail.com' \
    --to=bturner@atlassian.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git-for-windows@googlegroups.com \
    --cc=git-packagers@googlegroups.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).