Merged
Conversation
* simpler, easier to chop up with unix tools * show LFS OID, not Git SHA1 * only scan the tree, not the refs * show whether files are LFS pointers or full objects
Contributor
Author
|
@aorjoa: One more thing. We're not using the CLI package's built-in usage text anymore, so there's no point adding it to the flags definition. The help output is now rendered from the man pages directly: $ git lfs help ls-files
git lfs ls-files [<ref>]
Display paths of Git LFS files that are found in the tree at the given
reference. If no reference is given, scan the currently checked-out branch.
Options:
* -l --long:
Show the entire 64 character OID, instead of just first 10. |
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Feb 20, 2024
In commit 2082b26 of PR git-lfs#681 the "git lfs ls-files" command was enhanced to include in its normal output a simple symbolic indicator of whether a full copy of a Git LFS object existed as a file in the working tree, with a "*" character indicating the presence of such a file, and a "-" indicating the file's absence. While some tests were added at this time, none were added which check the command's output when a file is absent from the working tree. Later, in commit 1565e63 of PR git-lfs#2540, the --debug option was added to the "git lfs ls-files" command, which provides more extensive output, including separate Boolean fields indicating whether a Git LFS object exists as either a file in the working tree or as a cached object file. Again, while some tests were added for this new functionality, they do not check the cases where files are absent from either the working tree or the Git LFS object cache. As we expect to resolve a bug with the display of these data files in a subsequent commit in this PR, we first introduce a new test which validates the existing (and correct) behaviour. (Notably, this test only runs the "git lfs ls-files" command in the root of the working tree; if we executed the command while in a subdirectory, the output would not be correct, and this is the bug we will resolve in another commit in this PR.) We also add a test which confirms the same behaviour when the --json option is used. The use of a separate test for this option was preferred in PR git-lfs#5007 when the --json option was first introduced (rather than overloading the existing tests, as was done for the --debug option when it was added in PR git-lfs#2540), so we follow that model here as well.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Feb 22, 2024
In commit 2082b26 of PR git-lfs#681 the "git lfs ls-files" command was enhanced to include in its normal output a simple symbolic indicator of whether a full copy of a Git LFS object existed as a file in the working tree, with a "*" character indicating the presence of such a file, and a "-" indicating the file's absence. While some tests were added at this time, none were added which check the command's output when a file is absent from the working tree. Later, in commit 1565e63 of PR git-lfs#2540, the --debug option was added to the "git lfs ls-files" command, which provides more extensive output, including separate Boolean fields indicating whether a Git LFS object exists as either a file in the working tree or as a cached object file. Again, while some tests were added for this new functionality, they do not check the cases where files are absent from either the working tree or the Git LFS object cache. As we expect to resolve a bug with the display of these data files in a subsequent commit in this PR, we first introduce a new test which validates the existing (and correct) behaviour. (Notably, this test only runs the "git lfs ls-files" command in the root of the working tree; if we executed the command while in a subdirectory, the output would not be correct, and this is the bug we will resolve in another commit in this PR.) We also add a test which confirms the same behaviour when the --json option is used. The use of a separate test for this option was preferred in PR git-lfs#5007 when the --json option was first introduced (rather than overloading the existing tests, as was done for the --debug option when it was added in PR git-lfs#2540), so we follow that model here as well.
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
2 participants
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.
This builds on #680:
lfs.ScanTree()is used instead oflfs.ScanRefs(). Duplicate files are now shown.