commands: teach 'git lfs ls-files' a '--debug' option by larsxschneider · Pull Request #2540 · git-lfs/git-lfs

larsxschneider · 2017-08-29T22:00:56Z

There was no way to conveniently display LFS pointer file properties for
debugging. Teach 'git lfs ls-files' a '--debug' option that prints all
available information following the 'git ls-files' interface [1].

[1] git/git@8497421

--

If you like the approach of this PR, then this would this would replace #1829.
My goal here is a quick way to check the sizes of the Git LFS files in a repo.

Extract the logic that determines if a LFS file appears to be checked out properly. This refactoring should not change any behavior and it is useful for a subsequent commit.

ttaylorr

@larsxschneider this looks great, and I think this is a great approach and will supersede the pull request that you linked. Before merging, what do think about adding some integration tests to the test/test-ls-files.sh file given the --debug flag?

ttaylorr · 2017-08-30T01:57:08Z

docs/man/git-lfs-ls-files.1.ronn

 * `-l` `--long`:
  Show the entire 64 character OID, instead of just first 10.

+* -d --debug:


Can this be --extra?

It could although my intention was to match the git ls-files option: git/git@8497421
Up to you. Either way is fine with me 🙂

Ah, I did not know that git ls-files has --debug. I agree that we should continue to use that for consistency.

technoweenie

Really minor quibble about the output, but otherwise looks good to go 👍

I lean more towards --debug since it matches git ls-files, but don't have strong feelings either way.

technoweenie · 2017-08-30T16:00:01Z

commands/command_ls_files.go

+					"  checkout: %v\n"+
+					"downloaded: %v\n"+
+					"       oid: %s\n"+
+					"   oidtype: %s\n"+


I'd probably smash the oid into one line:

oid: %s %s oid: sha256 abcdef...

Agreed 👍

There was no way to conveniently display LFS pointer file properties for debugging. Teach 'git lfs ls-files' a '--debug' option that prints all available information following the 'git ls-files' interface [1]. [1] git/git@8497421

larsxschneider · 2017-08-30T21:48:35Z

test/test-ls-files.sh

+     oid: sha256 5aa03f96c77536579166fba147929626cc3a97960e994057a9d80271a736d10f
+ version: https://git-lfs.github.com/spec/v1
+
+EOF)


@ttaylorr Is this sufficient?

Looks great, thanks!

lfsapi: enable credential caching by default

The "git lfs ls-files" command was added in PR git-lfs#122 (technically, the precursor "git media ls-files" command) and its test suite converted to shell tests in PR git-lfs#336; however, the basic functionality of the command has never had tests which confirm it handles files in subdirectories appropriately. (Some tests added in later PRs which do check files in subdirectories under specific conditions, such as with the --exclude option or with non-ASCII characters in subdirectory names.) As we expect to expand this command's test suite in subsequent commits in this PR, we first add a new test which simply confirms that the normal output of the command, and the output with the --debug option, perform as expected when files have been both added and removed within a subdirectory. 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.

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.

As reported in the following issue comment, the "git lfs ls-files" command does not report the presence or absence of Git LFS object files in the working tree correctly unless the command is run the root directory of the working tree: git-lfs#1189 (comment) We resolve this problem by ensuring that the full, canonicalized path to the working tree is prepended by the fileExistsOfSize() helper function to the paths of the files whose presence it checks with the os.Stat() function. We then add two new tests which validate the correct behaviour of the command when it is run in a subdirectory of the working tree. These tests would fail without the accompanying bug fix to the command. We also add another two new tests which confirm 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.

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.

As reported in the following issue comment, the "git lfs ls-files" command does not report the presence or absence of Git LFS object files in the working tree correctly unless the command is run the root directory of the working tree: git-lfs#1189 (comment) We resolve this problem by ensuring that the full, canonicalized path to the working tree is prepended by the fileExistsOfSize() helper function to the paths of the files whose presence it checks with the os.Stat() function. We then add two new tests which validate the correct behaviour of the command when it is run in a subdirectory of the working tree. These tests would fail without the accompanying bug fix to the command. We also add another two new tests which confirm 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.

commands: refactor lsFilesMarker function

25a87db

Extract the logic that determines if a LFS file appears to be checked out properly. This refactoring should not change any behavior and it is useful for a subsequent commit.

larsxschneider requested review from technoweenie and ttaylorr August 29, 2017 22:00

ttaylorr reviewed Aug 30, 2017

View reviewed changes

technoweenie approved these changes Aug 30, 2017

View reviewed changes

commands: teach 'git lfs ls-files' a '--debug' option

1565e63

There was no way to conveniently display LFS pointer file properties for debugging. Teach 'git lfs ls-files' a '--debug' option that prints all available information following the 'git ls-files' interface [1]. [1] git/git@8497421

larsxschneider force-pushed the lars/debug branch from 10c66fb to 1565e63 Compare August 30, 2017 21:46

larsxschneider commented Aug 30, 2017

View reviewed changes

ttaylorr approved these changes Aug 30, 2017

View reviewed changes

LeszekKlonowski referenced this pull request Aug 31, 2017

Merge pull request #2508 from git-lfs/lfs-enable-credential-cache

6ffdf79

lfsapi: enable credential caching by default

ttaylorr merged commit 0a8d29d into master Aug 31, 2017

ttaylorr deleted the lars/debug branch August 31, 2017 02:02

larsxschneider mentioned this pull request Aug 31, 2017

RFC: add option "--size" to ls-files to print the file size #1829

Closed

chrisd8088 mentioned this pull request Jan 27, 2025

git lfs ls-files reports may incorrectly report objects as present or absent #5979

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

commands: teach 'git lfs ls-files' a '--debug' option#2540

commands: teach 'git lfs ls-files' a '--debug' option#2540
ttaylorr merged 2 commits intomasterfrom
lars/debug

larsxschneider commented Aug 29, 2017

Uh oh!

ttaylorr left a comment

Uh oh!

ttaylorr Aug 30, 2017

Uh oh!

larsxschneider Aug 30, 2017

Uh oh!

ttaylorr Aug 30, 2017

Uh oh!

technoweenie left a comment

Uh oh!

technoweenie Aug 30, 2017

Uh oh!

larsxschneider Aug 30, 2017

Uh oh!

larsxschneider Aug 30, 2017

Uh oh!

ttaylorr Aug 30, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

larsxschneider commented Aug 29, 2017

Uh oh!

ttaylorr left a comment

Choose a reason for hiding this comment

Uh oh!

ttaylorr Aug 30, 2017

Choose a reason for hiding this comment

Uh oh!

larsxschneider Aug 30, 2017

Choose a reason for hiding this comment

Uh oh!

ttaylorr Aug 30, 2017

Choose a reason for hiding this comment

Uh oh!

technoweenie left a comment

Choose a reason for hiding this comment

Uh oh!

technoweenie Aug 30, 2017

Choose a reason for hiding this comment

Uh oh!

larsxschneider Aug 30, 2017

Choose a reason for hiding this comment

Uh oh!

larsxschneider Aug 30, 2017

Choose a reason for hiding this comment

Uh oh!

ttaylorr Aug 30, 2017

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants