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

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2018-11-28 11:33:05 -04:00
commit 77c13ca3e8
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 32 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
doc/tips/Using_git-worktree_with_annex.mdwn Normal file
View file

@ -0,0 +1,18 @@
[Git worktrees](https://git-scm.com/docs/git-worktree) are supported since version 6.20180719.
Git normally makes a `.git` **file** in a
worktree, that points to the real git repository under `.git/worktrees/`.
This presents problems for git-annex. So, when used in a worktree,
git-annex will automatically replace the `.git` file with a symlink
pointing at the git repository. It also places an appropriate `annex` link
to `.git/worktrees/<name>/annex` to point to the object store. I don't know
how crippled filesystems are handled.
Getting, dropping and syncing content works fine in a worktree, however
if there is change in the tree then syncing doesn't update git worktrees
and their indices, but updates the checked out branches. This is different to
the handling of the main working directory as it's either got updated or left
behind with its branch if there is a conflict.
In its current state I use git-worktree to copy symlinks across branches and run `git annex fix`
on them. I only use temporary worktrees due to the syncing behavior.

14
doc/todo/add_limit_to_matching_options.mdwn Normal file
View file

@ -0,0 +1,14 @@
It would be really useful to have something like the limit option in SQL for matching options.
Here is a scenario where it makes sense, and which actually comes up for me quite a bit:
You have 2TB of files, where none of the files are larger than 1TB. You want to transfer the entire 2TB annex to another location (we'll call it target), but you can only do it with a single 1TB hard drive.
By being able to git annex copy . -t <1tb drive> --in=here --not --in=target --limit=1TB, I can ensure that an arbitrary group of any files, not to exceed 1TB, is copied to my transport drive. After I move the files from the transport drive to the target repo, I can repeat the process with the next 1TB.
I don't care which of the specific files are copied, I just want a subset of them copied, because they are part of a batch transfer job.
I often transfer files via mediums that have transfer limits, but I am eventually going to transfer all of them, so I don't have to care which ones are selected.
Currently, I've been using tricks to select a subset of the files, such as a range of file-sizes.