Track additional Git object information#6347
Merged
shanman190 merged 3 commits intomainfrom Dec 4, 2025
Merged
Conversation
This was referenced Nov 26, 2025
ae4ad2d to
bc26461
Compare
shanman190
commented
Dec 2, 2025
bc26461 to
8c1049b
Compare
Contributor
Author
|
These JS tests are known to be flaky, but are unrelated to the changes here. |
Contributor
Author
|
Interestingly enough, apparently Git only supports a couple of the posix file modes:
All other variations are reduced to their closest match. This makes the file mode portion a little less useful, but does situate us slightly better with respect to being able to understand the difference between a regular file and a symlink. It also could be the potential foundation needed to model submodules. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What's changed?
Create a new marker to track additional Git object information, presently scoped to Object ID.
Alternate name:
GitObjectId.What's your motivation?
For Git binary patch support, we have a need to go from
QuarktoRemote. In order to generate theindexline, this requires the old object id and the new object id. For other LST elements, we generate the object id on the fly by generating the sha1 of the raw printed bytes. ForQuark, this isn't possible and needs a different solution.Anything in particular you'd like reviewers to focus on?
N/A
Anyone you would like to review specifically?
Anybody
Have you considered any alternatives or workarounds?
We could have added the object id as a field on
QuarkorSourceFile, but it was preferred to utilize a dedicated marker instead.Any additional context
Another long standing issue is related to file mode. The current implementation of
FileAttributesis very lossy with respect to this information. A possibility would be to capture theFileMode#getBits()from JGit since it would cost O(1) to retrieve and add to this marker. Doing so, I'd probably suggest that we change the name of the marker to something else, such asGitTreeEntryto be more accurate of it's purpose.Additionally, on Windows,
Files#isExecutable(Path)always returns true. So this can manifest in the Git patch later as a file being marked as executable when it normally wouldn't be due to this JVM quirk.Checklist