mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Added a comment: thanks and the followup

Browse source
This commit is contained in:
psxvoid 2024-11-27 09:08:32 +00:00 committed by admin
parent da2d74a18a
commit 7502105629
1 changed files with 15 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
doc/forum/Stuck_in_git_annex_view__58___file_name_too_long/comment_3_08642e7f8c863d3b518517be2a5b4ae1._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="psxvoid"
avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
subject="thanks and the followup"
date="2024-11-27T09:08:32Z"
content="""
Thanks for posting your reasoning and for the fix, Joey!
> As to whether git-annex should try to detect this and avoid entering such a view, I dunno..
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.
"""]]