Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
bfceeeb13b
4 changed files with 60 additions and 0 deletions
|
@ -0,0 +1,3 @@
|
|||
What I mean is that I just want to effectively fetch the file contents from the special remote but without actually persisting them to the git annex repo.
|
||||
|
||||
My usecase is that I have a git annex repo in a cloud server with limited space backed by something like a huge S3 bucket. I now want to fuse mount this repo and access it's contents as needed while using git annex to manage files. I could ask git annex where the files are and then invoke that myself, but at that point I might as well manage it myself.
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="psxvoid"
|
||||
avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
|
||||
subject="ViFM Plugin Which Partially Solves The Issue"
|
||||
date="2024-12-31T06:16:08Z"
|
||||
content="""
|
||||
I wrote a proof of concept [plugin](https://github.com/psxvoid/vifm-git-mv) for [ViFM](https://github.com/vifm/vifm) which allows to move files around and replace `mv` command for such moves with `git mv`. It partially solves the issue - git detects such moves as renames. But because git annex makes \"fixup\" for symbolic links in pre-commit hook, then git detects file change as well. A workaround to this might be separating those operations into two commits - one with rename and another one with symlink fixup. However, I wish it were possible to do this in a cleaner way.
|
||||
"""]]
|
|
@ -0,0 +1,34 @@
|
|||
[[!comment format=mdwn
|
||||
username="psxvoid"
|
||||
avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
|
||||
subject="Update: rename in separate commits"
|
||||
date="2024-12-31T12:36:02Z"
|
||||
content="""
|
||||
Managed to find a semi-satisfactory approach to solve this rename problem:
|
||||
|
||||
1. rename files with `git mv`
|
||||
2. commit with `--no-verify` (e.g. `git commit --no-verify`)
|
||||
|
||||
Now, renamed symlinks should be broken, because we skip `git annex` hooks with `--no-verify`.
|
||||
|
||||
To fix it for the last commit, run:
|
||||
|
||||
```shell
|
||||
git show --name-status --oneline HEAD | grep R100 | cut -f3 | xargs -L 1 git annex fsck --fast -q
|
||||
```
|
||||
|
||||
And then do a commit again with whatever message you like (mine is `git commit -m \"Fix git-annex symlinks\"`).
|
||||
|
||||
There are a couple of inconveniences here:
|
||||
|
||||
1. There are more commands to run instead of just `git commit`
|
||||
2. In the git log now additional \"plumming\" commits
|
||||
|
||||
Hoverer, #2 is pretty easy to solve by running:
|
||||
|
||||
```shell
|
||||
git log --invert-grep --grep=\"Fix git[- ]annex symlinks\" -i
|
||||
```
|
||||
|
||||
Though, not sure yet how to deal with #1 - probably there is a way to automate it.
|
||||
"""]]
|
|
@ -0,0 +1,15 @@
|
|||
[[!comment format=mdwn
|
||||
username="psxvoid"
|
||||
avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
|
||||
subject="Workaround for WSL2 on Windows"
|
||||
date="2024-12-31T05:49:31Z"
|
||||
content="""
|
||||
Seems like a huge repository (mine is around 500GB) is barely feasible for git-annex on crippled filesystems. The workaround I'm currently using - is creating `.vhdx` virtual drives on Windows, attaching them to WSL2 and formatting as ZFS. Then I use it from WSL2. I've also made them available to Windows through FUSE `bindfs --resolve-symlinks` + samba share. This setup works almost all the time, except some programs (on Windows side) can't scan some directories with lots of files on samba due to timeouts. Though, it works perfectly inside the WSL2.
|
||||
|
||||
There are other downsides as well:
|
||||
|
||||
- files can't be accessed on a system without WSL2
|
||||
- `.vhdx` sometimes grows in size, and it's not always easy to shrink it back
|
||||
|
||||
What is probably feasibly on `ExFAT` especially on Linux - is using [nlinkfs](https://github.com/rene/nlinkfs) which can simulate symlinks on crippled file systems. In theory it might even be possible to build it for Windows and use with Dokan. But I haven't tried it.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue