Bump git2 from 0.14.2 to 0.15.0

[dependabot]

Bumps git2 from 0.14.2 to 0.15.0.

Commits

• 4461b17 Add binding for git_message_trailers (#749)
• 4348694 Merge pull request #756 from saimen/fix-diffstat-doc-typo
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[hwittenborn]

@sharkdp @Enselic any update for this? I'm wanting to add git2 to my application but I'm also using bat for syntax coloring, so I can't use the latest version.

[Enselic]

@dependabot rebase

[Enselic]

Seems like CI fails because 1.58 is too old. Do you know MSRV of git 0.15.0? So we can bump MSRV

[Enselic]

The MSRV policy of git2 is

git2-rs works with stable Rust, and typically works with the most recent prior stable release as well.

Since git2 is a core (albeit optional) dependency of bat, it would not be unreasonable for bat to adopt the same MSRV policy. It would certainly make life of bat maintainers easier, if it would work.

@sharkdp I think we should see what happens if we adopt the same MSRV policy. Are you OK with that? We can reverse the decision if we get a backlash.

[hwittenborn]

Do you know MSRV of git 0.15.0?

I don't, though due to my currently requirements I'm not using git2 directly in my application anymore, so this isn't really and issue for me rn, at least for the time being.

[Enselic]

Another option could be to run our MSRV CI pipeline without git support.

[Enselic]

Another option could be to run our MSRV CI pipeline without git support.

PR for that: #2279

[Enselic]

@dependabot rebase

[hwittenborn]

Another option could be to run our MSRV CI pipeline without git support.

Would this affect anything with how the end user application or lib is utilized?

[Enselic]

Not that I see. Did you have anything in particular in mind?

BTW, I was hoping that PR would fix CI. Not sure how to best fix the current failure.

[hwittenborn]

Not sure if I was thinking earlier @Enselic. Main issue for me atm is just getting this lib to the latest verison

[sharkdp]

Hm, strange. This issue (rust-lang/git2-rs#838) seems to indicate that 1.60 is needed for some reason, even though I don't understand why the MSRV build even requires the git2 dependency after your PR, @Enselic.

I'm a bit tired of this. Let's just move MSRV to 1.60 and then we will hopefully be good for a while. Even if git2s policy seems very lax, I don't think that they will intentionally break this all the time. At least not from the experience so far.

[sharkdp]

@Enselic Please feel free to merge this if you agree with the MSRV bump to 1.60 (which is rather recent). Should we still keep your no-git change for the MSRV CI run?

[Enselic]

Thanks for fixing, let's merge!

I think we should keep git away from MSRV because:

• We want to always be on latest git2 version, and Dependabot will ensure that we are
• The git2 MSRV policy is "latest stable"

I'm actually more and more thinking that instead of having a fixed MSRV we should have a fluid MSRV, like "3 stable releases back", and then update docs and CI jobs accordingly. So bumping MSRV to 1.60 is totally fine with me.

[sharkdp]

I'm actually more and more thinking that instead of having a fixed MSRV we should have a fluid MSRV, like "3 stable releases back", and then update docs and CI jobs accordingly. So bumping MSRV to 1.60 is totally fine with me.

Okay with me for bat. We should probably write a script (or an automation) to automatically do those replacements in README/CI files. Or update the READMEs and refer user to the CI script for current MSRV?

[Enselic]

I'm thinking we would write in READMEs "only last 3 stable releases are supported" or something like that.

But let me propose that we go even further: Why don't we make it so that latest bat requires latest Rust? With rustup it is super easy to use latest stable. And for users that use pre-packaged versions of bat, it does not matter.

Maybe we can try it, and if it turns out that it does not work out, we can always go back to "last 3 stable releases". We discussed maintenance burden before, and getting rid of MSRV would certainly ease maintenance burden, with for me unclear downsides.

The only downside I can think of is that people that use the version that comes with their distro (which is typically quite old) can't compile bat master branch. But I find it hard to imagine that that group of users has a significant size. Besides, they would be likely to get problems even with a "only last 3 stable releases are supported"-policy.

[Enselic]

I completely forgot about bat-as-a-library 🤦‍♂️

[sharkdp]

I would propose another strategy:

• We try to keep MSRV as low as possible for users of bat-as-a-library
• But as soon as there is only the slightest inconvenience for the developers/maintainers, we bump MSRV liberally (up to the current stable release, if neeeded)
• For that reason, we do not advertize our "MSRV policy". "It is what it is".
• Since we are going to bump MSRV often, we write a simple script that does the textual replacements, so that it becomes a simple ./set-msrv.sh 1.61.

[Enselic]

Sounds great, let's try it 👍