x-add-version: add option to automatically commit result

[autoantwort]

No description provided.

[autoantwort]

@BillyONeal can you review the code for Filesystem::relative? :)

[BillyONeal]

@BillyONeal can you review the code for Filesystem::relative? :)

Sorry I missed this message before. I generally don't think code review is very effective at finding bugs in unit level tests like this; I would prefer to see lexically_relative extracted with unit tests added, then change this function to one that combines with almost_canonical in a way where it need not be unit tested because there are no "interesting conditions", if that makes sense?

[autoantwort]

Should lexically_relative check if the given paths are absolute? Or is this simply undefined behavior?

[BillyONeal]

Should lexically_relative check if the given paths are absolute? Or is this simply undefined behavior?

The standard says that if absoluteness is different or similar that the result is path() (that is, an empty path). https://en.cppreference.com/w/cpp/filesystem/path/lexically_normal

[autoantwort]

Hm I don't want to reimplement the function lexically_relative with standard semantics. Especially when the only reason is that we want to run the tests on windows.

[BillyONeal]

Hm I don't want to reimplement the function lexically_relative with standard semantics. Especially when the only reason is that we want to run the tests on windows.

It's OK to implement your own function but if we are naming the function the same name as the standard I think it should do what the standard says unless we can't do that for some reason. (There's a notable exception with some of the copy/copy_file family enums, but in that case we just didn't implement some of the cases we didn't need, we didn't implement something different than what the standard said)

[BillyONeal]

I think this PR has been in a holding pattern because

1. We don't have a great understanding of what we want registry manipulation commands to be / do. This is part of why x-add-version still has the x-. I'm hoping to address this (as we also discussed in vcpkg command port-name should be consistent across commands vcpkg#18967 ) as part of going into Visual Studio slated to be ready in March.
2. We aren't sure we want to be creating commits. It's "out of character" for us to make 'durable' changes like that in any automated fashion.

If you're still interested in investigating here before we can give you a concrete answer, I can say something that would be uncontroversial would be fixing x-add-version to work with uncommitted changes. (By setting GIT_INDEX_FILE to a throwaway index, 'committing' into that, and using that to figure out what the tree SHA would be)

Sorry you've been in a holding pattern for so long

[autoantwort]

I thought it would be helpful because you currently always have to do a

1. git add versions
2. git commit --amend --no-edit or git commit -m "Add versions"

after running vcpkg x-add-versions no matter what. So it seemed logical to me to automate this.