Not sure why TestFsck() can't os.Stat() the LFS object file on the CI machine.
note: the next commit e934a82 is an unrelated typo fix.

do we want to look for LFS stuff in past commits?

I think there are at least 4 modes that we could support.

1. Scan HEAD + Index (default)
2. Scan a commit by name. git lfs fsck --commit abcdef
3. Scan .git/lfs/objects git lfs fsck --all
4. Scan EVERYTHING.

I think we can get away with 1-3. Scanning the entire git history isn't interesting unless you have everything downloaded already.

Thanks for the comments, @technoweenie . I'll make the changes. Before I add support for different modes, I'm going to push some temporary debug code to diagnose the os.Stat() error.

I'm going to push some temporary debug code to diagnose the os.Stat() error.

Use the testing package's Logf(). They only display on test runs that have the error, so there's no harm leaving them in after you fix the bug.

Alright, I'm stuck. I'm not sure why this works on my machine and not on the CI box, and the test is simple, so perhaps someone else could take a quick look.

TestFsck() is failing to find the LFS object corresponding to a LFS file after a commit. I have test code that recursively prints out the repo dir, and on the CI machine, there are simply no LFS objects under .git/lfs/objects. On my local machine, of course, everything works as expected.

If someone can help figure this out, that'd be awesome.

Additionally, I'd like to refactor TestFsck() a bit, but first I'd need to get clarification on how to run a bunch of commands on a TestRepository sequentially without the repo state getting cleared. Currently -- and several other unit tests like TestCleanPointer depend on this behavior -- func (r *Repository) test(path string)() invokes repo.clone() before each testCommand Run(), so it isn't possible.

Ugh, sorry about the sad state of integration testing here. I have some ideas on making it better.

The reason it's failing is because Git LFS isn't installed. You can replicate it locally by removing the clean filter:

$ git config --global --unset filter.lfs.clean

I'm going to update the test to manually write a bad file to .git/lfs/objects.

I have my own branch that uses your commits up until you started all those debug commits. I also changed the test so that it corrupts the file in the before callback. Once the test passes, I'd add a check in the after callback that ensures the file is gone.

I want to change the fsck behavior so that it just prints the errors to STDOUT without logging an error. We can probably just delete the corrupt object, and expect the client to download it on demand from the server.

$ git lfs fsck
Could not fsck Git LFS files:

Object a.dat (916f0027a575074ce72a331777c3478d6513f786a591bd892da1a577bf2335f9) is corrupt

I did some more work and opened a PR: #290. Still can't get the tests to pass though.

Also, I'm going to make #291 a priority of mine. Your testing experience in this PR is unacceptable.

Thanks for picking this up and taking on the testing issues.