Hi,
I was experimenting with tags today, and seems like switching to a tag view broke my repository. Now, even git status gives me an error, output:
...vi.srt: File name too long
nothing to commit, working tree clean
On branch views/main(tag=_)
Before that I ran git annex view tag=*.
What I'm thinking is that before switching to a tag view file name/path was fine, but during switching seems like git annex transformed the file name which exceeds the max file path.
For ZFS those limits are:
getconf NAME_MAX /pool-name
255
getconf PATH_MAX /pool-name
4096
Steps to reproduce:
- create a file in a directory with a long path
- create a tag
- switch to a tag
for example, here is one of the errors:
sizeďą•huge/02_getting-a-handle-on-vectors_%knowledge-storages%courses%authorities%coursera%linear-algebra-machine-learning%01_introduction-to-linear-algebra-and-to-mathematics-for-machine-learning%02_the-relationship-between-machine-learning-linear-algebra-and-vectors-and%.pl.srt: File name too long
I've tried the following commands, but due to this error nothing changes:
git annex vpop< says "git-annex: Not in a view."git checkout main< does nothing, stays "On branch views/main(tag=_)"git restore .< does nothing, stays "On branch views/main(tag=_)"
Is there anything can be done to at least go back to the main branch and clear the error?
Hi,
Seem like I've managed to fix it by openning
.git/HEADfile with VIM, and then changing:to this:
Saved the file, then ran
git stash --all. Which returned the repo to the original state.Also before
git stash --all, I rangit restore .git annex fsck, andgit add -Abut those didn't change anything.This can certainly happen if files in the repository are in a directory path that, when converted to a filename, is too long.
I tried reproducing it, and was basically able to get into the same state as you. The reason both "git-annex vpop" and "git checkout master" fail is that since the long files were staged in git, but unable to be written, git considers them to be deleted. And so it refuses to do a checkout, with "Your local changes to the following files would be overwritten by checkout"
I was able to resolve it by deleting the directory that contained those too long files. Which was empty anyway. That made git treat those files as deleted, and allowed "git checkout master" to work, as well as "git-annex vpop".
The reason "git-annex vpop" failed for you with "Not in a view" is that was actually the second time you ran it, and the first time, despite the git checkout failing, it had proceeded to update git-annex's state to say it had popped out of the view. I've fixed that bug.
As to whether git-annex should try to detect this and avoid entering such a view, I dunno..
Thanks for posting your reasoning and for the fix, Joey!
It's not that critical when you know how to fix it. Though, it was definitely putting a good amount of stress on me. I was starting to think that I have to re-create this particular "meta" repository, and at that moment I didn't have enough time/energy to do it. And even if re-creating it wouldn't be as difficult as I was imagining it back than, I decided to fix it, because if it would have happen in a non-meta repository, and I would having some non-synced changes, it could be very unpleasant. And I could imaging that it might happen to anyone.
Also, as a side note, I was thinking about creating a FUSE FS which could specifically handle such cases for metadata, e.g. by introducing a "virtual folder" in the root, e.g.
long-paths(don't like the naming, probably it needs more thinking). Such FUSE FS could potentially work along with the git-annex views, preserve the existing folder structure, but only showing files with specific tags/metadata.