stricter pointer spec #246
Merged
Conversation
This file contains 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
|
Awesome, thanks! |
| * Lines of key/value pairs MUST be sorted alphabetically in ascending order | ||
| (with the exception of `version`, which is always first). | ||
| * Values MUST NOT contain return or newline characters. | ||
| * Pointer files SHOULD not have the executable bit set when checked-in in Git. |
|
I think this is a good approach 👍 |
| * Lines of key/value pairs MUST be sorted alphabetically in ascending order | ||
| (with the exception of `version`, which is always first). | ||
| * Values MUST NOT contain return or newline characters. | ||
| * Pointer files SHOULD NOT have the executable bit set when checked-in in Git. |
|
I implemented a |
This was referenced Apr 24, 2015
Closed
rtyley
added a commit
to rtyley/git-lfs
that referenced
this pull request
Aug 31, 2015
In practice, Git LFS preserves the executable status of files when they are cleaned-to/smudged-from pointer files - in fact the [git attributes clean/smudge filter mechanism](http://git-scm.com/docs/gitattributes#__code_filter_code) doesn't actually provide any support for changing the executable status of file, they just work on the file's contents with standard input & output. This is good behaviour, because users don't want their big *.exe files to stop being executable when they start using Git LFS, and the executable status is not preserved anywhere else (eg. rightly, it is not stored within the pointer file). As an example, here are two *.exe files that have been stored with Git LFS, which has preserved their exec bit in the file tree object. Note that `bar.exe` has it's exec bit _set_ (`100755`), contrary to the spec: ``` $ git cat-file -p HEAD^{tree} 100644 blob ce8828c1134a1f9feb8177e9e2b988d94a94d951 .gitattributes 100644 blob 9242c60b11d49b42e829070feef1c5b7cf7a6159 foo.exe 100755 blob 25637885004ac19bd1e0404e2bb0d2247de37805 bar.exe $ git cat-file -p 25637885004ac19bd1e0404e2bb0d2247de37805 version https://git-lfs.github.com/spec/v1 oid sha256:364ea686b8d77dbf49d1c1ce28023e818954574310b68c61433fbb02596744e2 size 51200 ``` I think the spec just needs correcting here. The wording was introduced with git-lfs#246, tweaked with git-lfs@4bdecf, but I couldn't find any justification in those for the statement that the executable bit should always be cleared.
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.
Tightens up the pointer spec according from @swisspol in #233 and https://gist.github.com/swisspol/b9856fcca81029efb960.