-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect Git features (the GVFS Protocol) based on the version #407
Conversation
Add ability to determine Git features from the GitVersion. Currently only supports detecting GVFS Protocol support.
Support parsing normal Git version numbers (major.minor.build) as well as the existing Git for Windows and Microsoft Git style formats (major.minor.build.platform.revision.minorRevision).
Skip the GVFS protocol authentication check if the installed version of Git does not support the GVFS protocol (via the GVFS helper).
Add support for parsing Git builds that include release candidate components. Also support partially parsing local builds of Git that may have other version formats such as "2.28.0.456.gabcdefg.dirty".
Add trace logging to Git feature detection during `scalar clone`.
I'm not sure, but I think we're missing a few cases.
My installed version (from one of the CI builds) looks like:
|
(I'm not sure we can do anything with those formats, but I thought I'd mention they exist.) |
If the 4th component is a string ( We shouldn't be gating a feature of Git by something beyond that version, right? |
I agree that we shouldn't care about the details after the first 5 parts. I think @jeffhostetler just wants to add a unit test to ensure that we properly ignore those details. What do you think, @mjcheetham? |
I can add a test with that, and also a test with garbage after the first 4 components too, for good measure. |
Add another test of GitVersion parsing that includes nonsense version information, and Unicode (Emoji) characters - ensure this is parsed OK too.
@derrickstolee I'm not sure how we can test this E2E, given the inability to mock out the process creation, and that the version of Git installed would need to be different between test cases (meaning multiple new test jobs, with the difference being the installed version of Git)? |
The only automated test I can think of would be to set up a functional test build that only runs the "Vanilla Git repo" tests (using the I think for now, the unit tests are sufficient and we can worry about the actual compatibility at the functional level in a follow-up. |
Add a way to get a list of features that a version of Git supports, such as support for the GVFS protocol.
With this we can better handle and support users of Scalar that are not using Azure DevOps or the Microsoft fork of Git.
In the future we can also gate behaviour on other features such as
--changed-paths
.Implements #380
TODO:
CloneVerb
to respond to a lack of GVFS protocol support