Git LFS confuses Atom's git change detection

Question

Git LFS confuses Atom's git change detection

ruffsl opened this issue 8 years ago · 10 comments

edit by @rsese to mention repro steps from #68 (comment)

Finally had a chance to setup LFS again and test this out and I believe I can reproduce.

I installed and configured LFS on 2 computers (1 Windows and 1 Linux, both on 1.37.0), then setup and pushed a test repository as described in this LFS tutorial on computer 1.

Then I:

Cloned the repo on computer 2
Changed the LFS tracked file (head -c 1M /dev/urandom > cat.bin)
Add, commit, and push the change from computer 2
git pull from computer 1

At this point, cat.bin in the tree view is orange and git status reports that everything is up-to-date. I reloaded Atom as well and cat.bin remained in orange until I changed it locally on computer 1 and added/committed that change.

Just following up on this issue atom/atom#8291 that is thought to be rooted in this repo. From @envygeeks 's findings , looks like a lfs filter should be used. I'm unfamiliar with this codebase however.

Answer 1 · 2016-02-18T22:30:36.000Z

Thanks for the follow up, @ruffsl. I'm not sure who is the best person on the team to look into this, so I'm adding it to the internal queue.

Answer 2 · 2017-05-12T10:19:39.000Z

How is the follow up on this? I just installed atom and I have this problem on my lfs repository.

Answer 3 · 2018-09-21T03:51:06.000Z

Any progress on this? I have same issue with my Git-LFS repos

Answer 4 · 2019-05-15T14:02:04.000Z

I've just hit this bug with a Git LFS repo as well :-(

Answer 5 · 2019-05-15T14:59:27.000Z

@rsese would you mind seeing if you can reproduce this? See libgit2/libgit2#3373 for vague repro steps and let me know if you have questions.

Answer 6 · 2019-05-15T15:02:16.000Z

hmm, scratch my comment... I've no idea what has changed in my environment but I'm no longer seeing this bug a few minutes later. I wonder whether I hadn't pulled down the .gitattributes file for LFS earlier on or something silly like that. Right now, looks to be working just fine (Atom 1.30.0 on Linux).

Answer 7 · 2019-05-15T16:50:35.000Z

Thanks for the update @grahamwhiteuk, glad things are working for you now (as a side note, I see you're on 1.30.0 - just wanted to mention that the latest stable release version of Atom is 1.37.0 so you may want to update).

Can anyone else who was seeing this issue reproduce? If so, can you share specific steps to reproduce? I haven't played with LFS in a while so repro steps would be helpful for us when testing things out.

Answer 8 · 2019-05-16T08:37:22.000Z

So this morning I've git pulled and brought down some changes including some files from Git LFS and the problem has manifest itself again. So from my observations at the moment there doesn't seem to be a problem if I'm the one committing the change but if I pull changes from other people then I see the issue. Sorry, that probably doesn't help a huge amount but hoping to narrow it down a bit.

I'm on 1.35.0, typo above.

Answer 9 · 2019-05-30T22:35:50.000Z

Finally had a chance to setup LFS again and test this out and I believe I can reproduce.

I installed and configured LFS on 2 computers (1 Windows and 1 Linux, both on 1.37.0), then setup and pushed a test repository as described in this LFS tutorial on computer 1.

Then I:

Cloned the repo on computer 2
Changed the LFS tracked file (head -c 1M /dev/urandom > cat.bin)
Add, commit, and push the change from computer 2
git pull from computer 1

At this point, cat.bin in the tree view is orange and git status reports that everything is up-to-date. I reloaded Atom as well and cat.bin remained in orange until I changed it locally on computer 1 and added/committed that change.

Answer 10 · 2021-04-26T00:23:50.000Z

Follow-up: I've had same issue just now, but having a commit (removed an image file) solved the issue. I downloaded the git via Github desktop, initialized git lfs but had my yolo.h5 file marked orange. All github/lfs/atom using latest stable version.