Update to libgit2 37dba1a

[johnhaley81]

No description provided.

[johnhaley81]

This updates NodeGit to use the latest HEAD version of libgit2. We have a pretty good system to bring in changes and update NodeGit to use any arbitrary version of libgit2 so I'm thinking we should start doing more LTS releases for "stable" libgit2 and an EDGE release that tracks the head of libgit2 aggressively. I think having that up for discussion for @nodegit/owners would be good.

Summary of changes that were brought in:

libgit2/libgit2@37dba1a

Changes or improvements

• NodeGit.FetchOptions, and NodeGit.PushOptions now have a proxyOpts field that accepts a NodeGit.ProxyOptions object that allows NodeGit to use a proxy for all remote communication
• NodeGit.MergeOptions has a defaultDriver field that lets the caller change the driver used to when both sides of a merge have changed

API additions

• Commit.createWithSignature allows the caller to create a signed commit. There are no tests for this currently so it's labelled experimental.
• Blob, Commit, Tag, and Tree all have a new prototype dup method on them to make a low-level copy of the libgit2 object if needed.
• Odb#expandIds is exposed which takes in a list of short ids and expands them in-place to the full id of the object in the database

[tbranyen]

Edge releases help with migration so I'm 👍 to that idea

[johnhaley81]

Obligatory "I hate that our CI is so dependant on not having network latency"

[tbranyen]

I knowwwwww. I should take a staycation just to fix it.

[johnhaley81]

Ditto. Maybe a staycation with network fixes and doc updates :)

[tbranyen]

What do you think about tagging/publishing versions based off sha?

Version could be like libgit2-37dba1a

{
  "dependencies": {
    "nodegit": "libgit2-37dba1a"
  }
}

[johnhaley81]

@tbranyen how would that work with semver and npm publish?

[tbranyen]

The same way that alpha and beta releases work. Although I'm thinking this could/should be a third party provided service. Something like npmserve.io or something fancy and startupy. Basically it would fetch the commit SHA, do an npm install, followed by an npm pack and then serves you back the built version.

... back on topic, we could tag the releases named to the SHA (they would correctly break semver), but I don't think it'd be trivial with our current setup.

[johnhaley81]

I was thinking of having a maint/v0.x branch where we could backport fixes that are applicable to a version and just keeping that going for a few months or so. That or we could have NodeGit follow libgit2's version. I.e. NodeGit v0.23.x has libgit2 v0.23.x in it. That way the version of libgit2 in this would actually be v0.25 and we would release NodeGit v0.25 with this in it.

[maxkorp]

The issue with nodegit v 0.23.x matching libgit 0.23.x for example, is that what happens when we publish 0.23.4 to match libgit 0.23.4, but then we have more stuff to push to it? we'd have to go 0.23.5, but then if they get an 0.23.5, that tag is already taken.

[tbranyen]

@maxkorp something I mentioned in Gitter was adopting the Arch Linux method of maintaining versions while also updating. They simply tack on a -revision. So our versions would look like: 0.23.4-1 which bumps to 0.23.4-2. This works well within semver ranges, buuut breaks down hard if libgit2 doesn't release anything new and we have a major update to publish.

[tbranyen]

Hey @ashleygwilliams thanks for responding to me on Twitter. Our problem is outlined here, but the gist of it is that we tightly couple to the semantically versioned libgit2 project. We'd like to somehow marry the NodeGit version to the libgit2 version. This would be useful when libgit2 has massive overhauls and developers want to test changes before bumping to the next revision.

Is there a best practice for our use case? We've had some discussion above, but it feels like npm has a solution for this we can follow.

/cc @johnhaley81 can you fill any gaps I missed while writing this summary up?

[ashleygwilliams]

hey @tbranyen just to be clear on what you are trying to do, here's what i think i understand you want the workflow to be, in chronological order:

• nodegit is at a version X.Y.0
• libgit2 publishes to version X.Y.1
• nodegit should auto update libgit2 and auto publish X.Y.1
• nodegit has additional updates, does a revision X.Y.2-1

This works well within semver ranges, buuut breaks down hard if libgit2 doesn't release anything new and we have a major update to publish.

not entirely sure how to handle that yet given this solution that you've laid out. given that conflict,after talking this over with @soldair, it sounds like you really have 2 things that need to be versioned, libgit2 wrapping and nodegit features, and so splitting this and the libgit2 wrapper might be your best option. the wrapper stays in sync with libgit2 and then you can version all of nodegit features as you would normally. this also gets rid of the somewhat clunky revision portion.

[tbranyen]

@ashleygwilliams yeah you got what we're trying to do. the approach you mentioned is a really interesting idea. @johnhaley81 what do you think about separating the wrapper from the "library" and independently versioning them.

I'll have to think a bit more about this since it wasn't an option I was considering before

Edit: Thanks for your response!

[johnhaley81]

Sorry for the delay :)

So a few more things to note, we'd like to have an "Edge" version that follow libgit2#master and more stable versions that follow published releases. So this works for publishing against tagged versions but fails in the "edge" case which is the original wrench that I threw into this thing to start this whole mess. I'm not totally sure what to do in that situation.

We could do something like libgit2Wrapper@0.<x>.0.rc.<y> where x is libgit2's latest minor release version + 1 and y is whatever version we at nodegit had previously + 1. @ashleygwilliams does npm respect semver pre-release numbering?

[soldair]

npm does support sorting ranges of prerelease versions. But! please separate the prerelease fragment with a dash.

var sv = require('semver')
console.log(sv.sort(['0.1.0-rc.0','0.1.0-rc.2','0.2.1','1.0.0','0.1.0-rc.22']))

[ '0.1.0-rc.0', '0.1.0-rc.2', '0.1.0-rc.22', '0.2.1', '1.0.0' ]

i may have missed the question but hope this helps =)

[johnhaley81]

@soldair thanks! Would we also be able to put the hash of the libgit2 commit in there as well?
e.g. 0.25.0-rc1.37dba1a. We'd bump the rc# each time to for an update but the sha on the version would be a quick-and-easy way to see the exact version of libgit2 being used on the "edge" version of the wrapper.

[ashleygwilliams]

hey! this is not my mountain, but my 2 cents is that this is doing way too much with the version number. you've lost human readability (if you cared about that) and the complexity makes project onboarding and maintenance difficult. i would suggest going back to first principles of the problem you are trying to solve cuz it feels like we're in deep weeds now.

[johnhaley81]

We decided to backport fixes that don't break API for maintenance releases and have the rest of NodeGit move forward with edge releases. Thanks all for the input!