remove old closed bugs and todo items to speed up wiki updates and reduce size
Remove closed bugs and todos that were last edited or commented before 2024. Except for ones tagged projects/* since projects like datalad want to keep around records of old deleted bugs longer. Command line used: for f in $(grep -l '|done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2024 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2024 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done for f in $(grep -l '\[\[done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2024 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2024 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done
This commit is contained in:
Joey Hess
parent
0000c3f325
commit
2fe36b35a2
871 changed files with 0 additions and 27861 deletions
|
|
@ -1,5 +0,0 @@
|
|||
since there is no generic 'fuse' mode, I would like to request to have `--get` (or `--auto-get`) option for diffdriver. I am trying to compare files across two branches on a repo I just cloned. I cannot download all the files and downloading differing keys across branches for the same file is a bit painful. So I felt that it would be super nice if git annex could auto get those files from somewhere (well -- original clone)
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2018-02-08T17:28:21Z"
|
||||
content="""
|
||||
This is a good idea. I wonder what to do about the objects it downloads for
|
||||
a diff; should they be left in the annex for later use/dropunused, or
|
||||
immediately deleted after the diff completes.
|
||||
|
||||
My inclination is to keep
|
||||
them around, for one thing when I'm diffing stuff I often run diff more
|
||||
than once, perhaps to widen the diff or because I want to take a second
|
||||
look at it, and re-downloading a bunch of big files would be painful then.
|
||||
|
||||
By the way, what diffdriver program are you using? I've had a hard time
|
||||
finding any real-life examples of git diffdrivers.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 2"
|
||||
date="2023-08-09T05:31:26Z"
|
||||
content="""
|
||||
How about handling them as if they were manually fetched with `git annex get`? The next run of `satisfy`, `sync`, etc. will then take care of dropping.
|
||||
"""]]
|
||||
|
|
@ -1,95 +0,0 @@
|
|||
Thank you for `git-annex`, it's awesome!
|
||||
|
||||
I recently figured I could add `git-annex metadata` to my research data files that contains the start and end date of timeseries data inside the files so a quick lookup by date range (”which files contain data in that time range”) is possible.
|
||||
|
||||
This is possible when using numeric timestamps (e.g. unix timestamp like `1669981463`) but not with stringy dates (e.g. `2022-11-12T20:10:14+0200`) as `--metadata fieldname>=VALUE` does _numeric_ comparison.
|
||||
|
||||
## Proposal: How about when `--metadata fieldname>=VALUE` falls back to string comparison when `VALUE` can't be parsed as a number?
|
||||
|
||||
## Test case
|
||||
|
||||
Consider this script `make-git-annex-dir-with-timestamps.sh`:
|
||||
|
||||
```sh
|
||||
#/bin/sh
|
||||
fmt="$1";test -n "$fmt" || fmt="%FT%T%z"
|
||||
# make a new git annex repository
|
||||
d=git-annex-with-times-"$fmt";chmod +w -R "$d";rm -rf "$d";mkdir "$d";cd "$d"
|
||||
git init
|
||||
git annex init
|
||||
# create some files
|
||||
for i in `seq 1 9`;do echo "File $i" > "file$i";done
|
||||
git annex add .
|
||||
git commit -m "Add files"
|
||||
# add metadata to files
|
||||
for i in `seq 1 9`;do
|
||||
time_start="$(date -d"$((-20 + $i)) hours" +"$fmt")"
|
||||
(set -x;git annex metadata --set time-start="$time_start" "file$i")
|
||||
time_end="$(date -d"$((-10 + $i)) hours" +"$fmt")"
|
||||
(set -x;git annex metadata --set time-end="$time_end" "file$i")
|
||||
done
|
||||
timerange_start="$(date -d "-16 hours -5 minutes" +"$fmt")"
|
||||
timerange_end="$(date -d "-12 hours +5 minutes" +"$fmt")"
|
||||
(
|
||||
set -x
|
||||
git annex find \
|
||||
"-(" --metadata "time-start>=$timerange_start" --and --metadata "time-start<=$timerange_end" "-)" \
|
||||
--or \
|
||||
"-(" --metadata "time-end>=$timerange_start" --and --metadata "time-end<=$timerange_end" "-)"
|
||||
)
|
||||
echo "⬆⬆⬆ This should only output file4 through file8 ⬆⬆⬆"
|
||||
```
|
||||
|
||||
Invoked with unix timestamps time format, it works as expected:
|
||||
|
||||
```sh
|
||||
> ./make-git-annex-dir-with-timestamps.sh '%s'
|
||||
# ...
|
||||
+ git annex find '-(' --metadata 'time-start>=1669923315' --and --metadata 'time-start<=1669938315' '-)' --or '-(' --metadata 'time-end>=1669923315' --and --metadata 'time-end<=1669938315' '-)'
|
||||
file4
|
||||
file5
|
||||
file6
|
||||
file7
|
||||
file8
|
||||
⬆⬆⬆ This should only output file4 through file8 ⬆⬆⬆
|
||||
```
|
||||
|
||||
However, other stringy date formats match all files:
|
||||
|
||||
```bash
|
||||
# typical ISO-ish time format
|
||||
> ./make-git-annex-dir-with-timestamps.sh "%FT%T%z"
|
||||
# ...
|
||||
+ git annex find '-(' --metadata 'time-start>=2022-12-01T20:49:37+0100' --and --metadata 'time-start<=2022-12-02T00:59:37+0100' '-)' --or '-(' --metadata 'time-end>=2022-12-01T20:49:37+0100' --and --metadata 'time-end<=2022-12-02T00:59:37+0100' '-)'
|
||||
file1
|
||||
file2
|
||||
file3
|
||||
file4
|
||||
file5
|
||||
file6
|
||||
file7
|
||||
file8
|
||||
file9
|
||||
⬆⬆⬆ This should only output file4 through file8 ⬆⬆⬆
|
||||
```
|
||||
|
||||
```sh
|
||||
# git-annex's own time format for 'FIELDNAME-lastchanged'
|
||||
> ./make-git-annex-dir-with-timestamps.sh "%Y-%m-%d@%H-%M-%S"
|
||||
# ...
|
||||
+ git annex find '-(' --metadata 'time-start>=2022-12-01@20-38-04' --and --metadata 'time-start<=2022-12-02@00-38-04' '-)' --or '-(' --metadata 'time-end>=2022-12-01@20-38-04' --and --metadata 'time-end<=2022-12-02@00-38-04' '-)'
|
||||
file1
|
||||
file2
|
||||
file3
|
||||
file4
|
||||
file5
|
||||
file6
|
||||
file7
|
||||
file8
|
||||
file9
|
||||
⬆⬆⬆ This should only output file4 through file8 ⬆⬆⬆
|
||||
```
|
||||
|
||||
Yann / @nobodyinperson
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2022-12-12T17:06:40Z"
|
||||
content="""
|
||||
I think this is a good idea. Particularly there was no good reason for
|
||||
it to default to false when either value is not a number.
|
||||
|
||||
I've implemented this.
|
||||
"""]]
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 2"
|
||||
date="2022-12-22T11:39:41Z"
|
||||
content="""
|
||||
Thanks joey! However I don't think it works quite now. Slightly modifying the script above I made a [testsuite](https://gitlab.com/-/snippets/2475815) and it seems metadata fields are still interpreted as numbers somehow:
|
||||
|
||||
```bash
|
||||
# old version without lexicographical ordering
|
||||
❯ git annex version --raw
|
||||
10.20221212-gab11fd70e
|
||||
❯ bash make-git-annex-dir-with-timestamps.sh %s %Y%m%d%H%M%S %Y.%m%d%H%M%S %Y:%m%d%H%M%S %Y-%m-%dT%H%:M:%S %Y-%m-%dT%H%:M:%S%z %FT%T %FT%T%z
|
||||
%s ok
|
||||
%Y%m%d%H%M%S ok
|
||||
%Y.%m%d%H%M%S ok
|
||||
%Y:%m%d%H%M%S fail
|
||||
%Y-%m-%dT%H%:M:%S fail
|
||||
%Y-%m-%dT%H%:M:%S%z fail
|
||||
%FT%T fail
|
||||
%FT%T%z fail
|
||||
|
||||
# new version apparently with lexicographical ordering but no change
|
||||
❯ git annex version --raw
|
||||
10.20221213-gac6ccb513
|
||||
❯ bash make-git-annex-dir-with-timestamps.sh %s %Y%m%d%H%M%S %Y.%m%d%H%M%S %Y:%m%d%H%M%S %Y-%m-%dT%H%:M:%S %Y-%m-%dT%H%:M:%S%z %FT%T %FT%T%z
|
||||
%s ok
|
||||
%Y%m%d%H%M%S ok
|
||||
%Y.%m%d%H%M%S ok
|
||||
%Y:%m%d%H%M%S fail
|
||||
%Y-%m-%dT%H%:M:%S fail
|
||||
%Y-%m-%dT%H%:M:%S%z fail
|
||||
%FT%T fail
|
||||
%FT%T%z fail
|
||||
|
||||
```
|
||||
"""]]
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2022-12-22T18:30:46Z"
|
||||
content="""
|
||||
Thanks for double-checking. I have not tried your test but I think I see
|
||||
what is going on from the pattern. Strings starting with a number but then
|
||||
subsequently not a number were still being parsed to numbers and compared
|
||||
numerically. I've fixed that now.
|
||||
"""]]
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 4"
|
||||
date="2022-12-23T09:39:57Z"
|
||||
content="""
|
||||
Now it works, thank you very much joey! 🎉
|
||||
|
||||
```bash
|
||||
❯ ./make-git-annex-dir-with-timestamps.sh
|
||||
+ git annex version --raw
|
||||
10.20221213-g29176f131
|
||||
%s ok
|
||||
%Y%m%d%H%M%S ok
|
||||
%Y.%m%d%H%M%S ok
|
||||
%Y:%m%d%H%M%S ok
|
||||
%Y-%m-%dT%H:%M:%S ok
|
||||
%Y-%m-%dT%H:%M:%S%z ok
|
||||
%FT%T ok
|
||||
%FT%T%z ok
|
||||
```
|
||||
|
||||
(I had a typo in the above tests - a `%` out of place - but it didn't change the picture, now everything works as expected anyway.)
|
||||
"""]]
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 5"
|
||||
date="2022-12-23T10:05:26Z"
|
||||
content="""
|
||||
A very nice benefit of this feature is that we can now `git annex find` files depending on when their metadata was changed:
|
||||
|
||||
```sh
|
||||
# annexed files which have recently had their metadata changed
|
||||
git annex find --metadata \"lastchanged>=$(date -d'2 days ago' +%Y-%m-%d@%H-%M-%S)\"
|
||||
|
||||
# annexed files which have their tag changed in a specific week
|
||||
git annex find --metadata \"tag-lastchanged>=2022-12-18\" --and --metadata \"tag-lastchanged<=2022-12-25\"
|
||||
```
|
||||
"""]]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
I have some Git Annex repos that I keep copies of on both NTFS on Linux and on ecryptfs (which Ubuntu uses for home directory encryption) on Linux. Now, ecryptfs allows each path component of a filename to be only up to 140-ish characters, because it has to encrypt that filename, add some encryption info to it, and store it inside another filename on a backing ext4 filesystem (which limits path components to 255 characters).
|
||||
|
||||
Several times now I've added a bunch of stuff to my annex on the NTFS checkout, where path components are allowed to be longer than 140 characters, synced it over to my other annex checkout on ecryptfs, and then had Git Annex fail during the sync, trying to create these empty symlinks with path components too long for the filesystem it is on. When in this state, I don't really know how to fix it. I can't just "git mv" the offending file to a valid name, both because "git mv" needs the source file to be on disk in the first place and because the failed "git checkout" leaves my repo thinking it has thousands of untracked files (because some stuff did get created, but git refused to officially move to the commit it was trying to check out, because the checkout failed).
|
||||
|
||||
I am looking for a solution for this inside Git Annex. The simplest thing, I think, would be to set a max path component length for the whole set of repos, so I could get an error when I go to "git annex add" on the NTFS checkout that the filenames being added are too long for some of the repos that will eventually want to check them out. Is it possible to do this with a pre-commit hook somehow?
|
||||
|
||||
The next simplest thing would be for Git Annex to look at the filesystem it is running on and do something smarter than exploding and leaving my repo in a weird out-of-sync state if some of the filenames it wants to create can't be created. Maybe it should fail the sync earlier, in Git Annex itself rather than in git checkout. Maybe it should just leave those files out of the checkout, or force/allow me to rename them right then.
|
||||
|
||||
The most complex thing would be to somehow make it work anyway and check out the symlinks under different, valid names. Perhaps it could just truncate those path components in the symlink view? There's already support for different metadata views; this would be sort of like that. You get a special view of the repo subject to the constraints of your filesystem.
|
||||
|
||||
> [[rejected|done]] --[[Joey]]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
Thank you for your previous message here: [[/todo/Copy-on-Write__47__reflink_support_for_unlocked_files/]].
|
||||
|
||||
I indeed discovered it was done for Linux after I posted it, but macOS with APFS also supports reflinks, under the `-c` (clonefile) option, which does the same as the `--reflink=always` option on Linux.
|
||||
|
||||
The biggest problem is that there is no auto option, but in theory it’s possible to first try the clone option, and then fall back if it doesn’t work, although that would be inefficient.
|
||||
|
||||
I can try to code something, although I am not that proficient in Haskell, or run test code if needed on macOS 12.
|
||||
|
||||
-- Lena Wildervanck
|
||||
|
||||
> [[dup|done]] --[[Joey]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2022-11-21T19:11:52Z"
|
||||
content="""
|
||||
This todo aleady exists for the same thing:
|
||||
<https://git-annex.branchable.com/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/>
|
||||
"""]]
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Some filesystems, like BTRFS or ZFS have copy on write support, which means that if files are copied in a special way they share sectors until one of the files is edited. Implementing support would make files take up less space if they are in unlocked mode and not significantly edited.
|
||||
|
||||
> Already [[done]]. I did add a mention of it to the tip. --[[Joey]]
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="lena.wildervanck@4b6aac156870f72a36b090e210e4747f702b69cb"
|
||||
nickname="lena.wildervanck"
|
||||
avatar="http://cdn.libravatar.org/avatar/8a423528476e6f6dc6a06588b5bbf457"
|
||||
subject="comment 1"
|
||||
date="2022-11-13T19:03:48Z"
|
||||
content="""
|
||||
Oh, nvm, there already seem to be some references in the code to it.
|
||||
|
||||
Maybe it should be added that it does that under [[https://git-annex.branchable.com/tips/unlocked_files/]] under using less disk space?
|
||||
|
||||
Also, macOS uses a `-c` flag instead of `reflink`, according to [the cp man page](https://www.unix.com/man-page/mojave/1/cp/).
|
||||
"""]]
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
Currently, git-annex handles merge conflicts of annexed files well. It makes two differently named versions of the conflicting files (A more descriptive naming scheme including date and commit hash would be nice, but that's a different topic).
|
||||
|
||||
However, a conflict of git-tracked files is not resolved, leading to merge conflicts being left open after a `git annex sync` (thus leaving file contents with the weird merge markers `<<<<<` etc., breaking file contents.)
|
||||
|
||||
Could `git annex [resolve]merge` be extended to also handle those git conflicts and leave the repo in a clean, merged state after `git annex sync|pull|assist`?
|
||||
|
||||
To not confuse users, it could be opt-in (`git annex --set annex.resolvegitmerge true`), but maybe the default for `git annex assist`?
|
||||
|
||||
On conflict, it would remove the conflicting file and instead create two versions with suffixes either like annexed files or better the commit hash and/or date.
|
||||
|
||||
Submodule conflicts can't be resolved like this, in that case I would use the most recent commit of the two in question.
|
||||
|
||||
> [[rejected|done]] --[[Joey]]
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2023-06-05T18:49:43Z"
|
||||
content="""
|
||||
I think this would violate least surprise. Users expect git-annex
|
||||
to behave like git, and that means merge conflicts like git handles them,
|
||||
when the files are text files tracked by git.
|
||||
|
||||
Consider that, if the file is a config file, applying git-annex's
|
||||
resolvemerge to it would make 2 files with different names be in the
|
||||
repository. So the config file would stop taking effect for whatever it was
|
||||
supposed to configure. It would be easy for the user to miss that, because
|
||||
the repository would not be left in a conflicted state.
|
||||
|
||||
When you check a file into git rather than git-annex, you are
|
||||
choosing to have git manage that file normally. If you want the git-annex
|
||||
behavior, you can check the file into git-annex.
|
||||
"""]]
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
When fsck'ing a remote repo, files seem to be copied from the remote to a local dir (thus written to disk), read back again for checksumming and then deleted.
|
||||
|
||||
This is very time-inefficient and wastes precious SSD erase cycles which is especially problematic in the case of special remotes because they can only be fsck'd "remotely" (AFAIK).
|
||||
|
||||
Instead, remote files should be directly piped into an in-memory checksum function and never written to disk on the machine performing the fsck.
|
||||
|
||||
> [[done]] per my comments --[[Joey]]
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2021-04-14T17:07:50Z"
|
||||
content="""
|
||||
Only some remotes support checksums in-flight; this recently includes
|
||||
downloads from other git-annex repositories over ssh. Progress
|
||||
on that front is being tracked at
|
||||
<https://git-annex.branchable.com/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/>
|
||||
Most special remotes can't yet, but that should change eventually
|
||||
for at least some of them.
|
||||
|
||||
I've made fsck notice when content was able to be verified as part of a
|
||||
transfer, and avoid a redundant checksum of them.
|
||||
|
||||
What I've not done, and don't think I will be able to, is make the file
|
||||
not be written to disk by fsck in that case. Since the `retrieveKeyFile`
|
||||
interface is explicitly about writing to a file on disk, it would take ether
|
||||
a whole separate interface being implemented for all remotes that avoids
|
||||
writing to the file when they can checksum in flight, or it would need
|
||||
some change to the `retrieveKeyFile` interface to do the same.
|
||||
|
||||
Neither seems worth the complication to implement just to reduce disk IO in
|
||||
this particular case. And it seems likely that, for files that fit in
|
||||
memory, it never actually reaches disk before it's deleted. Also if this is
|
||||
a concern for you, you can I guess avoid fscking remotes too frequently or
|
||||
use a less fragile medium?
|
||||
"""]]
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2021-10-14T15:55:14Z"
|
||||
content="""
|
||||
Checksum during transfer is now implemented for as many remotes as it
|
||||
reasonably can be, which is almost all of them. But not 100% of all
|
||||
remotes in all circumstances. And there's no way to know if a remote
|
||||
will support it before doing the transfer.
|
||||
|
||||
To avoid changing the API, it occurs to me that retrieveKeyFile could be
|
||||
passed `/dev/null`. But any remote that does not support resuming and tries
|
||||
to overwrite the existing destination file would fail.
|
||||
|
||||
Also some kinds of remotes download to the file in one process or thread
|
||||
and while the download is happening, git-annex checksums the file as new
|
||||
data appears in it. External special remotes in particular do this.
|
||||
That would break with `/dev/null` too.
|
||||
|
||||
Putting the temp file on some other medium seems like the only way to
|
||||
address this. If there were a config of a directory to use, you could point
|
||||
it at a disk rather than the SSD, or even at a ram disk, if you have
|
||||
sufficient memory. Unsure if it's worth adding such an option though,
|
||||
probably few people would use it. And cloning the repository onto the other
|
||||
medium and running the remote fsck from there would have the same result
|
||||
without needing an option.
|
||||
|
||||
I'm inclined to close this, since I don't think it can be addressed.
|
||||
"""]]
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
Hey joey,
|
||||
|
||||
Currently, there is no one-command-to-rule-them-all to actually 'get the repo synced entirely'. Current workarounds:
|
||||
|
||||
[[!format bash """
|
||||
# plain git-annex
|
||||
git annex add
|
||||
(git add -A) # for the weird filter issues, see https://github.com/datalad/datalad/issues/7268
|
||||
git annex sync --content
|
||||
|
||||
# with DataLad
|
||||
datalad save # no way around the weird filter issues currently
|
||||
git annex sync --content
|
||||
"""]]
|
||||
|
||||
Whenever I introduce new people to git annex, it's always a pain point to explain these multiple steps. It would be awesome to have just one command that syncs everything. Especially for beginners.
|
||||
|
||||
`git annex sync` already does quite a bit including `git add`ing and `git commit`ting changes to tracked files. However it doesn't add new files. It would be awesome if `git annex sync` could optionally also do `git annex add`:
|
||||
|
||||
[[!format bash """
|
||||
# configure 'git annex sync' to run 'git annex add' before as well (opt-in)
|
||||
git annex config --set annex.syncadd true
|
||||
# have it sync the content as well
|
||||
git annex config --set annex.synccontent true
|
||||
|
||||
# From then on, 'git annex sync' does a *real* sync: everything that's new/changed here gets pushed elsewhere and new changes get pulled as well.
|
||||
git annex sync
|
||||
|
||||
# This would then basically be a poor-mans-git-annex-assistant 😛
|
||||
while true;do git annex sync --content;done
|
||||
"""]]
|
||||
|
||||
|
||||
What do you think?
|
||||
|
||||
Cheers, Yann
|
||||
|
||||
> [[done]] as `git-annex assist` --[[Joey]]
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 10"""
|
||||
date="2023-05-18T17:45:44Z"
|
||||
content="""
|
||||
Implementing `git-annex assist` now...
|
||||
|
||||
A tricky point is, should it add files only in the current directory and
|
||||
below, or all files in the repository? Note that the assistant can be run
|
||||
in a directory and it will only add changed/new files in that directory,
|
||||
although it can receive pulls that change files in other directories
|
||||
(and will then download those files content).
|
||||
|
||||
OTOH, `git-annex sync` commits all changes, not only those in the
|
||||
current directory. (The assistant does in some circumstanges commit
|
||||
changes made outside the current directory. Its behavior is a bit
|
||||
inconsistent in this area.)
|
||||
|
||||
So I think it makes sense for `git-annex assist` to only add files in the
|
||||
current directory by default. (Of course an option like -A could be added
|
||||
later.)
|
||||
|
||||
And while I'm a bit ambivilant about it, I'm making it commit all staged
|
||||
changes, not only those in the current directory. As well as following the
|
||||
behavior of `git-annex sync` and to an extent the assistant, it seems to
|
||||
me that if you run `git-annex add ../foo; git-annex assist`, you are
|
||||
intentionally building up a commit that includes file "foo". The same
|
||||
as if you ran `git-annex add ../foo; git-annex add .` ... If you're not,
|
||||
and you care about what files get added in what commit, you can of course
|
||||
commit manually.
|
||||
"""]]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="👍 git annex assist"
|
||||
date="2023-05-19T05:54:43Z"
|
||||
content="""
|
||||
Cool, joey!
|
||||
|
||||
I personally would like `assist` to add all changes in the entire repo by default. For beginners it's always a hassle to know what directory one is in and if one opens a terminal in a subfolder via a file manager, then run `git annex assist`, it won't sync all changes.
|
||||
|
||||
But I see that this would be inconsistent with `git annex add`... On the other hand, `assist` should help you easily sync the repo state without typing too much. One can always do `git annex assist .` for only this directory. A `-A` option is also an option, but effectively one would need to use it every time. As you said in the other comment - if you want more control, use the lower level commands. The assistant makes syncing a no-brainer, `git annex assist` should do so, too.
|
||||
|
||||
That the assistant can operate on only a subdir (do people do this?) itself is again an inconsistency then... A config like `annex.assistaddall` could be introduced, but meh...
|
||||
"""]]
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 12"""
|
||||
date="2023-05-19T18:37:28Z"
|
||||
content="""
|
||||
I'm also not too happy with the inconsistency of assist committing all staged
|
||||
changes and syncing all file contents, but only adding files in the cwd.
|
||||
|
||||
I suppose that consistency with the assistant doesn't really matter. The
|
||||
assistant's behavior when ran in a subdirectory is surprising,
|
||||
inconsistent, and undocumented.
|
||||
|
||||
So I'm going to change assist to add all files. Except when -C is used,
|
||||
then only add files in the specified directory.
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 13"
|
||||
date="2023-05-20T06:03:30Z"
|
||||
content="""
|
||||
Sounds good! Maybe also a `-m` short form of `--message` for less typing. Consistent with sync and datalad save.
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 14"""
|
||||
date="2023-05-23T15:46:27Z"
|
||||
content="""
|
||||
Oh, this new command and sync always supported -m. I've added it to the man
|
||||
page.
|
||||
"""]]
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="ewen"
|
||||
avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
|
||||
subject="Breaking change to "sync""
|
||||
date="2023-07-12T10:21:03Z"
|
||||
content="""
|
||||
Via a comment on [my bug about the new `sync` warning suddenly appearing in 10.20230626](https://git-annex.branchable.com/bugs/Changing_sync_to_include_content_breaks_UX/?updated) I see that this fairly hidden discussion seems to have been the rationale for completely changing what \"sync\" does \"because some users expect it to do everything\".
|
||||
|
||||
At the beginning of the design I might have agreed with you about \"what the sync command should do\" (and having another, eg, \"metasync\" command for the smaller version). But changing a fundamental command, a decade later, to do something different, based entirely on a \"wouldn't it have been nice (for some use cases) if...\" seems quite a stretch.
|
||||
|
||||
As per the other bug, if you want to implement new behaviour for such a fundamental command (\"git annex sync\" is something one runs pretty constantly if using git annex actively from the command line) then it'd be best to implement it in another command name, instead of dramatically changing an existing one. (The other thread has a few more suggestions; I personally still like \"fullsync\" for the expanded version.)
|
||||
|
||||
Either way, such a major -- behaviour breaking -- change needs to be much better documented than \"discussion in a bug that a few people saw\", and a note in passing in a changelog (which people have to find by noticing strange new output in probably scripted git annex usage).
|
||||
|
||||
Ewen
|
||||
|
||||
PS: I too think it's a terrible idea to have git annex default to auto-adding any files it can find. Maybe that makes some \"Dropbox-like\" use cases nicer, but it also entirely breaks other long standing use cases.
|
||||
"""]]
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="Clarification"
|
||||
date="2023-07-12T11:29:41Z"
|
||||
content="""
|
||||
@ewen for the record:
|
||||
|
||||
I never suggested that `git annex sync` auto-adds new files by default, see [my comment above](http://git-annex.branchable.com/todo/Having___39__git_annex_sync__39___optionally_add/#comment-37c3eb24df11d85c07b78c0297447c45):
|
||||
|
||||
> Exactly, I also would never want git annex sync to do the adding by default - strictly as an opt-in configuration.
|
||||
|
||||
As `git annex sync` already had so many options for configuring its behaviour, I thought having one more that runs `git annex add` in the beginning wouldn't hurt. I never suggested changing `git annex sync`'s default behaviour. Purely opt-in. Same for the existing options like `annex.synccontent` etc.
|
||||
|
||||
Changing `git annex sync`'s default behaviour of now syncing content was joey's idea, not mine.
|
||||
|
||||
> if you want to implement new behaviour for such a fundamental command
|
||||
|
||||
There is already `git annex assist` to do exactly that. See above or the changelogs.
|
||||
|
||||
Just to clarify. Please read the discussions you're referring to thoroughly before claiming things between the lines. 🙂
|
||||
|
||||
Now back to constructive discussion.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="adding all files or only in current directory?"
|
||||
date="2023-05-03T14:23:04Z"
|
||||
content="""
|
||||
`git annex add` only adds files in the current directory and below and has no flag to do a `git add -A` equivalent. For the purpose of making `git annex sync` also adding all files (e.g. with `git annex sync --add` or with prior `git annex config --set annex.syncadd true`), such an `git annex add --all|-A` option would be handy (which would also be used by `git annex sync --add`). It would also make `git annex add` more consistent with `git add`.
|
||||
"""]]
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="Git Alias for a 'full sync'"
|
||||
date="2023-05-15T07:31:41Z"
|
||||
content="""
|
||||
This alias pretty much does what I mean:
|
||||
|
||||
[[!format perl \"\"\"
|
||||
# set the alias
|
||||
git config --global alias.sync '!sh -xc '\"'\"'cd \"$(git rev-parse --show-toplevel)\";git annex add;git add -A;git annex sync'\"'\"''
|
||||
# This then goes into the repo root, adds stuff with git annex, adds the rest git-annex didn't add and syncs with git annex
|
||||
git sync
|
||||
\"\"\"]]
|
||||
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2023-05-15T20:09:30Z"
|
||||
content="""
|
||||
I don't think this can possibly become the default behavior, because plenty
|
||||
of users will have temporary files that they don't want to add (and haven't
|
||||
gitignored), or even sensitive files that happen to be in the same
|
||||
repository that it would be a security hole level surprise for `git-annex
|
||||
sync` to start adding, when it has not before.
|
||||
|
||||
For the same reason, `git-annex config` couldn't be used to make this a
|
||||
default `git-annex sync` behavior. A local git config to enable it would be
|
||||
ok.
|
||||
|
||||
It would would need to look at annex.largefiles, and add small files to git
|
||||
directly.
|
||||
"""]]
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 4"
|
||||
date="2023-05-15T21:13:34Z"
|
||||
content="""
|
||||
Exactly, I also would never want `git annex sync` to do the adding by default - strictly as an opt-in configuration.
|
||||
|
||||
I see your point that people might have sensitive files in a repo that they don't have `.gitignore`d and would not want to get pushed. However, I argue:
|
||||
|
||||
- If you clone a git annex repo and do `git annex sync` on it, you're pretty much already trusting that repo and the remotes. You either already have push access (that doesn't happen easily unless you're in control of the repo) or you don't, but then it's not a problem when you add your sensitive files because your changes won't ever get synced back. Even if they do at some later point: You `git annex drop --force` them (or just `git rebase -i`) to remove them from the repo entirely and worst case is that the file metadata is leaked back into the repo collection. Again, something I'd consider OK if you trust the repo.
|
||||
- When you trust a git annex repo, you also trust its `git annex config` settings like `synccontent` and consent with it.
|
||||
- Thus, if that repo has a `git annex config --set annex.syncadd true` setting that has `git annex sync` also do a prior `git annex add`, that's fine.
|
||||
|
||||
I think that only having a local `git config annex.syncadd true` setting is basically the same as having a customized alias like mine above, so that doesn't really improve the situation: in both cases users of the repo need to do local configs. A `git annex config` will be stored in the repo and be immediately effective for everybody using it - a major benefit for collaboration, for which git annex is a golden tool. If I understand correctly, any `annex.*` config can be overridden locally with a `git config annex.*` setting (right?). So cautious users can have `git config --global annex.syncadd false` to prevent `git annex sync` from ever adding files, even if the repo is configured to do so.
|
||||
|
||||
If the `git config annex.syncadd true` setting would just literally run `git annex add`, it automatically obeys the largefiles settings (also from the .gitattributes file).
|
||||
|
||||
All in all I'd consider the `syncadd` a matching feature considering how much `git annex sync` is already doing: committing, pulling, merging, pushing all over the place - only the adding it doesn't do.
|
||||
|
||||
The more behaviour can be configured in the repo directly, the better the out-of-the-box experience for (inexperienced) end users of a repo will be. I maintain many git annex repos and collaborate with different students like this on scientific projects. Together with [default preferred content expressions](https://git-annex.branchable.com/todo/Setting_default_preferred_content_expressions/) the workflow would be extremely straight-forward:
|
||||
|
||||
[[!format bash \"\"\"
|
||||
# get the repo
|
||||
git clone URL/repo
|
||||
cd repo
|
||||
# ”whenever you're done, run”:
|
||||
git annex sync
|
||||
# - auto-enables common remotes
|
||||
# - auto-sets preferred content expressions (to prevent the repos from uselessly downloading EVERYTHING - just what's sensible by default)
|
||||
# - auto-adds/commits/pulls/merges/pushes changes
|
||||
# - auto-syncs content around
|
||||
\"\"\"]]
|
||||
|
||||
Sensible settings for largefiles in `.gitattributes` or the `git annex config` can be set by those who understand it, others just do `git annex sync` and are done with it.
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 5"""
|
||||
date="2023-05-16T16:32:51Z"
|
||||
content="""
|
||||
sync's intent is to replicate as close as possible the following common
|
||||
git workflow:
|
||||
|
||||
first stage some changes, and then run:
|
||||
git commit -m foo
|
||||
git pull
|
||||
git push
|
||||
|
||||
Since git-annex has some complications involving pulling and pushing
|
||||
the git-annex branch, and transferring the content, it adds a learning
|
||||
curve that was too high. Giving users one new command to learn minimizes
|
||||
the learning curve. (It's unfortunate it didn't originally send content,
|
||||
and annex.synccontent aims to fix that oversight and I hope it may eventually
|
||||
become default.)
|
||||
|
||||
For git-annex sync to default to doing something not in the above
|
||||
pull+commit+push workflow would be surprising, because that's the workflow
|
||||
users have been told it handles.
|
||||
|
||||
Notice that the git-annex assistant will happily add all files to the
|
||||
repository and send their content. That's because it's *not* targeting
|
||||
users who expect to use that git workflow. So it's not surprising that it
|
||||
does what it does.
|
||||
|
||||
In conclusion, if having this behavior enabled by git config is not useful,
|
||||
then it does not belong in `git-annex sync`. It could go in a new command.
|
||||
"""]]
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 6"""
|
||||
date="2023-05-16T17:05:35Z"
|
||||
content="""
|
||||
I also generally feel like `git-annex sync` was probably a bad conflation
|
||||
of 3 git commands into 1 command when there could have just been `git-annex
|
||||
pull` and `git-annex push`. The fact that it conflates several things makes
|
||||
users think of it as just a big "does all the things" command, which makes
|
||||
users want it to do more things.
|
||||
|
||||
It is not too late to split it up, and eventually deprecating it would be a
|
||||
good path to making annex.synccontent default.
|
||||
|
||||
Update: Implemented `git-annex pull` and `git-annex push`, although I have
|
||||
no plans yet to deprecate `git-annex sync`.
|
||||
|
||||
Update: I found a better path to transition to sync --content by
|
||||
default, and have started that transition. `git-annex pull/push` sync
|
||||
content by default already.
|
||||
"""]]
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 7"""
|
||||
date="2023-05-17T17:24:03Z"
|
||||
content="""
|
||||
Brainstorming some names for a new command that is `git add -A` + sync...
|
||||
|
||||
`git-annex publish` kind of implies more exposure of local files to others
|
||||
than just syncing. But it more implies sending data, not also receiving it.
|
||||
|
||||
`git-annex addsync` is clear what it does, but not very memorable.
|
||||
|
||||
`git-annex assist` has a nice analogy to the `git-annex assistant`,
|
||||
which is close in behavior. Users who don't know about the assistant
|
||||
will miss the analogy though. "assist" also suggests git-annex will take
|
||||
care of everything, even more broadly than sync.
|
||||
|
||||
`git-annex share` also implies more exposure of local files than git-annex
|
||||
sync, and sharing goes both ways so it's better than `git-annex publish`.
|
||||
|
||||
I'd be inclined toward `git-annex share` or `git-annex assist`, but welcome
|
||||
better ideas.
|
||||
"""]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 7"
|
||||
date="2023-05-17T10:41:18Z"
|
||||
content="""
|
||||
Cool, thanks joey!
|
||||
|
||||
If you want to go as far as deprecating `git annex sync` (a huge change in habits for git-annex users if that one goes away), I wonder how adding the `annex.syncadd` config (a strictly opt-in consensus for users of a repo) is too much of a disruption 😅 But okay, you're the maintainer.
|
||||
|
||||
I still think that having **one command** that does what the assistant does, but as a one-shot manual step, would benefit git-annex immensely. I recently tried running the assistant on my SailfishOS phone (https://fosstodon.org/@nobodyinperson/110203412944552425) and realised that having the assistant running in the background all the time is not ideal due to e.g. the power consumption - maybe due to the permanent SSH connection to the remotes. I am now using a systemd service that basically does `git annex add;git annex sync`. Would be awesome and certainly good for the understanding of new users if there was a command that basically one-steps the assistant - This is something I as a previous Syncthing user was dearly missing: one-stepping the syncing to see what's the bottleneck/problem/what it does exactly, etc. If you'd rather put this into a new command, I'm fine with that, though I still think `git annex sync` is a perfect candidate also due to the name.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 9"
|
||||
date="2023-05-18T08:40:37Z"
|
||||
content="""
|
||||
Good suggestions, I'd prefer `assist`, as it'll be one step of what the assistant does. I'll also through `git annex update` into the ring. `update`ing goes both ways, `share`ing also sounds more like you getting your stuff out there, not necessarily others' stuff to you.
|
||||
"""]]
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
Thank you joey for `git annex diffdriver --text`, that is a big step towards easier diffing of annexed files. The following is now a copy-paste solution to 'make git diff work with git annex':
|
||||
|
||||
```
|
||||
echo '* diff=annextextdiff' >> .git/info/attributes && git config diff.annextextdiff.command "git annex diffdriver --text"
|
||||
```
|
||||
|
||||
This however then has `git diff` use git-annex' diffing mechanism for *all* files, including normal git-tracked files. There probably is no gitattributes-way of applying a diff command only to annexed files, right?
|
||||
|
||||
## Customizing `diff` options
|
||||
|
||||
Apparently, `git annex diffdriver --text` uses the system's `diff` command and doesn't (allow to) give it any specific options. The below points could be worked around by having something like `git annex diffdriver --text --diffopts='--color=auto'` so that the user can customize the `diff` invocation. Alternatively you could introduce an environment variable like `GIT_ANNEX_DIFFDRIVER_DIFF_OPTIONS` or shorter `GIT_ANNEX_DIFF_FLAGS` that could also be used to temporarily diff *that one file* with specific options.
|
||||
|
||||
## Coloring the output
|
||||
|
||||
How about passing the (sanitized, `false`→`never` and `true`→`auto`) `git config color.diff` (and fallback `color.ui`) setting as the `diff --color=...` option? The experience would then match the users configured expectation.
|
||||
|
||||
|
||||
## Handling all files as text
|
||||
|
||||
`diff` detects some files as binary, although it can make sense to text-diff them (e.g. PDFs), just to get an impression of the changes. `diff` (and `git diff` as well, AFAIK without any good workaround without an external driver again) then just displays the unhelpful message that the 'binary files differ' (you don't say...🙄).
|
||||
|
||||
How about having `git annex diffdriver --text` always using `diff --text`? That would deviate from the usual `git diff` behaviour, but I argue that:
|
||||
|
||||
- a) People *explicitly* configure (a subset of) files in `.gitattributes` to be diffed with `git annex diffdriver --text`.
|
||||
- b) If they wouldn't care about the diff between files, then they wouldn't configure it.
|
||||
- c) Tracking binary(-like) files is something git-annex is explicitly designed for, it makes sense that git just skips over those, but git-annex could add value here
|
||||
|
||||
Thanks again a ton for git-annex, the Tübix2023-Workshop was well appreciated and lots of fun. 👍
|
||||
|
||||
Yann
|
||||
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2023-07-05T18:55:33Z"
|
||||
content="""
|
||||
If your annexed files have a common extension you can match them in
|
||||
.gitattributes that way.
|
||||
|
||||
I've added support for passing options for diff. Eg:
|
||||
|
||||
git annex diffdriver --text -- --color --text --
|
||||
|
||||
As for passing --color automatically, I don't know if every diff(1) supports
|
||||
--color, and this would be more complexity.
|
||||
|
||||
I doubt that most users would appreciate diff --text by default for large
|
||||
binary files. That is really getting into territory that an external
|
||||
diff driver program can handle much better. Eg, if you're diffing jpegs and
|
||||
also zip files, you can write a diff driver program that lists the contents of
|
||||
zip files and passes that to diff, and that uses imagemagick
|
||||
`compare -compose` or <https://github.com/x1ddos/imgdiff>
|
||||
to show a visual diff between two jpegs.
|
||||
|
||||
The point off the --text option is that sometimes you know you have plain
|
||||
text and so writing such a program is not necessary.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 2"
|
||||
date="2023-07-06T05:44:57Z"
|
||||
content="""
|
||||
Wonderful, thank you joey!
|
||||
"""]]
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
Hello,
|
||||
|
||||
while reading the release notes of git 2.11 I noticed a cool new feature has been merged:
|
||||
|
||||
> If the filter command (a string value) is defined via
|
||||
> `filter.<driver>.process` then Git can process all blobs with a
|
||||
> single filter invocation for the entire life of a single Git
|
||||
> command.
|
||||
|
||||
see the [git documentation][1].
|
||||
|
||||
This has been developed in the context of git-lfs (see [PR 1382] [2]).
|
||||
|
||||
If I understand correctly how it works this could speed up v6 repos. Looking at the history/website
|
||||
of git-annex there doesn't seem to be yet any work on this so I though it was worth calling the
|
||||
attention on the feature.
|
||||
|
||||
Thanks a lot for all the work on git-annex, it's a really amazing project! The more I study it the more cool features I discover :)
|
||||
|
||||
|
||||
[1]: https://github.com/git/git/blob/v2.11.0/Documentation/gitattributes.txt#L384
|
||||
[2]: https://github.com/git-lfs/git-lfs/pull/1382
|
||||
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2016-12-13T15:57:05Z"
|
||||
content="""
|
||||
Yes, this will make [[smudge]] faster when eg checking out a lot of working
|
||||
tree changes. I will need to add support for it.
|
||||
"""]]
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2018-08-13T20:24:02Z"
|
||||
content="""
|
||||
The "filterdriver" branch implements support for these.
|
||||
|
||||
However, it's actually slower than the old interface, because the new
|
||||
interface requires git-annex read the whole file content from git when
|
||||
adding a file, and the old interface let it not read any content.
|
||||
|
||||
Since the new interface does have capabilities, a new capability could
|
||||
prevent schepping the content over the pipe, and let the filter driver
|
||||
refer to the worktree file instead, and respond with the path of a file.
|
||||
This would be similar to my old patch set for the old interface.
|
||||
"""]]
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2018-10-26T16:21:28Z"
|
||||
content="""
|
||||
While `git add` would be a lot slower when using this interface to add
|
||||
large files, it would make `git checkout` and other commands that update
|
||||
the work tree a lot faster.
|
||||
|
||||
Since the smudge filter is not providing git with the file content any more,
|
||||
using filterdriver would avoid git running many git-annex smudge processes,
|
||||
greatly speeding up large checkouts.
|
||||
|
||||
Unfortunately, `git annex smudge --update` ends up running the smudge filter
|
||||
on all files that the clean filter earlier acted on, so even if filterdriver were
|
||||
used to speed up the clean filter, there would still be one process spawned per
|
||||
file for the smudge filter.
|
||||
|
||||
So some interface improvement is needed before git-annex can usefully use
|
||||
this.
|
||||
"""]]
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
Hi joey,
|
||||
|
||||
How about making `annex.addunlocked` configurable similar to `annex.largefiles` so different file types can be configured to be added unlocked and others locked?
|
||||
|
||||
The following illustrates a use case:
|
||||
|
||||
[[!format bash """
|
||||
#!/bin/sh -x
|
||||
# make a repo
|
||||
export LC_ALL=C.UTF-8
|
||||
chmod -R +w addunlocked;rm -rf addunlocked
|
||||
git init addunlocked
|
||||
cd addunlocked
|
||||
git annex init
|
||||
# configure *.txt files to be added unlocked so they stay editable
|
||||
echo '*.txt annex.addunlocked=true' > .gitattributes
|
||||
git add .gitattributes
|
||||
git commit -m "Add .gitattributes"
|
||||
# make a note
|
||||
echo bla > notes.txt
|
||||
git annex add
|
||||
git annex sync -m "add notes.txt"
|
||||
# However editing doesn't work as it was added locked
|
||||
echo blubb >> notes.txt # fails as it was not added unlocked
|
||||
"""]]
|
||||
|
||||
Probably not all matching options (like `copies` for example) make sense or work at all in this context, but at least `include=` would be useful („all files in that dir should be added unlocked always”). For example, in a synced folder for collaboration, PDFs could stay locked to save space, but Spreadsheets and ODT documents for example make sense to be added unlocked by default to stay editable. This could be achieved with something like this:
|
||||
|
||||
[[!format bash """
|
||||
# repo-wide stored in git-annex branch
|
||||
git annex config --set annex.addunlocked 'include=*.odt or include=**.pdf'
|
||||
|
||||
# folder-specific via .gitattributes
|
||||
echo '*.pdf annex.addunlocked=true' >> .gitattributes # (or 'anything')
|
||||
echo '*.odt annex.addunlocked=true' >> .gitattributes # (or 'anything')
|
||||
|
||||
# repo-specific
|
||||
git config annex.addunlocked 'include=**/*.odt or include=**/*.pdf'
|
||||
"""]]
|
||||
|
||||
What do you think?
|
||||
|
||||
Cheers, Yann
|
||||
|
||||
> [[notabug|done]] --[[Joey]]
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 1"
|
||||
date="2023-06-06T12:54:35Z"
|
||||
content="""
|
||||
[git annex matching options](https://git-annex.branchable.com/git-annex-matching-options/) that make sense for `annex.addunlocked`:
|
||||
|
||||
- include
|
||||
- exclude
|
||||
- mimetype
|
||||
- mimeencoding
|
||||
- largerthan
|
||||
- smallerthan
|
||||
- (securehash)
|
||||
- (inbackend)
|
||||
|
||||
All the others won't work AFAICS because location tracking hasn't yet happened at adding time.
|
||||
"""]]
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2023-06-06T16:50:16Z"
|
||||
content="""
|
||||
annex.addunlocked can already be set to a [[git-annex-matching-expression]]
|
||||
and this allows configuring it differently for different filenames, etc.
|
||||
This has been supported since 7.20191230.
|
||||
|
||||
You can already configure annex.addunlocked with `git-annex config`.
|
||||
|
||||
Adding gitattributes for configs is problimatic because querying
|
||||
for them is not fast. They have to be queried for every file. Also the
|
||||
gitattributes format is not well suited to complex expressions since the
|
||||
value cannot contain spaces.
|
||||
|
||||
The only benefit to supporting it in gitattributes would be to configure it
|
||||
differently in different branches of the repository.
|
||||
|
||||
There was a todo already suggesting this,
|
||||
[[annex.addunlocked_in_gitattributes]] and I decided to close it.
|
||||
"""]]
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="comment 3"
|
||||
date="2023-06-07T04:49:04Z"
|
||||
content="""
|
||||
Heh, didn't check that as I assumed when gitattributes does't work, git annex config won't either. Different branch config is a point but I guess not a huge one, right.
|
||||
|
||||
Maybe a note about addunlocked would fit into the docs: https://git-annex.branchable.com/git-annex-add/
|
||||
"""]]
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2023-06-12T20:29:05Z"
|
||||
content="""
|
||||
I've updated the man page to document annex.addunlocked.
|
||||
"""]]
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
### Please describe the problem.
|
||||
Changing metadata while being in an active view will not update the view.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
(inside a repository)
|
||||
|
||||
1. Create a file
|
||||
|
||||
$ uuidgen >file
|
||||
|
||||
2. switch into a view
|
||||
|
||||
$ git annex view !blah
|
||||
$ ls
|
||||
file
|
||||
|
||||
3. changed the metadata the view is based upon
|
||||
|
||||
$ git annex metadata -t blah file
|
||||
$ ls
|
||||
file
|
||||
|
||||
It would be nice/expected that the view gets updated when the metadata changes, hiding 'file' now
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
git-annex version: 5.20141024~bpo70+1
|
||||
on debian wheezy with backports
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2015-07-20T17:45:13Z"
|
||||
content="""
|
||||
This might be worth adding. But, one of the ways views can be used
|
||||
is to use file operations to adjust the metadata that is being viewed.
|
||||
|
||||
So, when you delete a file from a view, and git commit, git-annex
|
||||
will remove the metadata that had made the file be in the view.
|
||||
|
||||
And, if you copy or move a file in a view to a different subdirectory,
|
||||
and add and git commit the change, the metadata will be updated to
|
||||
update the metadata to reflect the files new location.
|
||||
|
||||
As such, I see this as a wishlist todo item at best, and will move it from
|
||||
the bugs list to the todo list.
|
||||
"""]]
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="👍 +1 for updating the view when committing"
|
||||
date="2023-02-03T13:25:21Z"
|
||||
content="""
|
||||
I'd also love to see the current view being updated to reflect the new metadata after committing. Workaround is currently to `git switch` back to the main branch and re-make the view with `git annex view bla='*'`.
|
||||
|
||||
BTW views are **really** cool, what an awesome idea, joey!
|
||||
"""]]
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2023-02-08T16:29:36Z"
|
||||
content="""
|
||||
Another time it would make sense to update the view is after git pull from
|
||||
elsewhere, which could change the metadata, or change the files present in
|
||||
the parent branch. I think it would make sense for `git-annex sync` run in
|
||||
a view to update the view after pulling.
|
||||
|
||||
Updating the branch after `git-annex metadata` is run locally is of course
|
||||
also possible. There is a similarity to updating an adjusted branch after
|
||||
get/drop. Which has a config annex.adjustedbranchrefresh to tune how
|
||||
frequently to update the branch. Or the user could just run
|
||||
`git-annex sync --no-pull --no-push` themselves.
|
||||
|
||||
There is probably a lot of scope for optimisation in updating the view
|
||||
branch, that might be able to get it reasonably quick.
|
||||
I have not fully thought through it, but basically diffing from the old
|
||||
parent branch to the new parent to find files that have changed, and
|
||||
adding/removing those from the view. And also diffing from the old
|
||||
git-annex branch tree to the new one to get changes to metadata logs,
|
||||
parsing those and using changes to metadata to also move/delete/add
|
||||
files to the view branch.
|
||||
|
||||
But it would be ok to start with a simple, slow implementation.
|
||||
"""]]
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2023-02-08T19:32:34Z"
|
||||
content="""
|
||||
`git-annex sync` when in a view branch will now update it.
|
||||
|
||||
Leaving this open for optimising it.
|
||||
|
||||
Also because of this problem:
|
||||
|
||||
joey@darkstar:~/tmp/m#master(author=_)>git-annex sync
|
||||
commit
|
||||
On branch views/master(author=_)
|
||||
nothing to commit, working tree clean
|
||||
ok
|
||||
merge synced/master
|
||||
fatal: refusing to merge unrelated histories
|
||||
failed
|
||||
|
||||
Looks like it should not be trying to merge the synced/master
|
||||
branch into the view branch. But, this makes me wonder, does the master branch
|
||||
get updated with new files pulled from remotes? If not, the view branch
|
||||
won't be updated to have them either.
|
||||
|
||||
Also, I think that it may try to import trees from importree special remotes,
|
||||
into the view branch. Perhaps those should also get imported but merged into
|
||||
the master branch...
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="`git annex sync` when in view"
|
||||
date="2023-02-08T20:17:12Z"
|
||||
content="""
|
||||
Right, git refusing to merge unrelated histories is something I also bumped into while developing `thunar-plugins`. There I worked around it by having the *Synchronize* menu item do `git add -A;git commit -m ...;git annex sync --only-annex`, which works fine.
|
||||
"""]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 6"""
|
||||
date="2023-02-10T19:49:51Z"
|
||||
content="""
|
||||
I've now fixed `git-annex sync`'s other behavior when ran in a view branch
|
||||
to be acceptable.
|
||||
|
||||
I'm going to close this as fixed. But have opened
|
||||
[[faster_incremental_update_of_view_branch_by_git-annex_sync]] as the
|
||||
performance could be improved.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="👍 This made it easier for the Thunar plugin!"
|
||||
date="2023-02-14T09:35:32Z"
|
||||
content="""
|
||||
[`thunar-plugins`](https://gitlab.com/nobodyinperson/thunar-plugins) now detect git annex' support for this (checking if `view` appears in `git annex help sync`, which it didn't before) and does `git annex sync` instead of the `git add -A;git commit;git annex sync --only-annex` workaround in that case. Very nice, joey!
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 8"""
|
||||
date="2023-02-14T16:17:05Z"
|
||||
content="""
|
||||
I'd recommend not relying on the `git-annex help sync` to detect this,
|
||||
since man pages may not be available. Look for '?=' in
|
||||
`git-annex view --help`
|
||||
"""]]
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Would it be possible to create a package for Lacie's NacOS?
|
||||
|
||||
> [[closing|done]] --[[Joey]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2016-01-20T18:56:36Z"
|
||||
content="""
|
||||
If that is a Linux-based NAS, there's a reasonably good chance that one
|
||||
of the [Linux standalone builds](https://git-annex.branchable.com/install/Linux_standalone/)
|
||||
of git-annex will run on it.
|
||||
|
||||
Actually, from what I can see, it's based on Debian, so you might be able
|
||||
to just apt-get install git-annex
|
||||
"""]]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="db"
|
||||
subject="comment 2"
|
||||
date="2016-01-22T19:00:57Z"
|
||||
content="""
|
||||
Yes it is Linux:
|
||||
|
||||
$ uname -a
|
||||
Linux nas 3.10.59-svn15282 #1 SMP Fri Jul 31 13:36:10 UTC 2015 x86_64 GNU/Linux
|
||||
|
||||
But it does not have apt. And probably not a compiler either.
|
||||
|
||||
Is it complicated to install a compiled version manually? Or is it \"self-containing\"? Any instructions for cross compiling on a Mac?
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2016-01-22T19:39:17Z"
|
||||
content="""
|
||||
Get a build from
|
||||
<https://git-annex.branchable.com/install/Linux_standalone/>
|
||||
"""]]
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
I'd like to be able to set a fixed limit on how much storage can be uploaded to a special remote. A use case for this may be that I want to spend no more than Y dollars, on a storage service that charges $X per gigabyte. I would thus set a limit where I a upload would be interrupted with a warning about the limit, and to continue I would need to use a --force option.
|
||||
|
||||
> dup of [[Specify_maximum_usable_space_per_remote]]; [[done]] --[[Joey]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2015-07-02T20:01:42Z"
|
||||
content="""
|
||||
This totally makes sense to want, but it's rather difficult to implement since
|
||||
multiple git-annex repos can all be uploading content to the same special
|
||||
remote, while disconnected from each other.
|
||||
"""]]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="mawillcockson"
|
||||
subject="comment 2"
|
||||
date="2015-07-18T19:13:03Z"
|
||||
content="""
|
||||
Perhaps server-side [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)?
|
||||
|
||||
Maybe a git hook script that uses [inotify](https://en.wikipedia.org/wiki/Inotify) for inode size notifications.
|
||||
|
||||
I would have no idea how to implement this, though.
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
I noticed that `git annex diffdriver` doesn't make sure that files it tries to diff are actually present. Would it make sense that `git annex diffdriver ...` runs `git annex get` to ensure files are present? 🤔 A `git diff` could then result in a lot of traffic if the user configured the `diffdriver`. But I'd say that users who took their time to configure would be are aware of this or even expect that to happen - after all they want to see the differences to a past version.
|
||||
|
||||
A manual workaround is to handle the `get`ting in a custom supplied diffing program.
|
||||
|
||||
Context:
|
||||
|
||||
- [recently added `git annex diffdriver --text`](https://git-annex.branchable.com/todo/Improving_diffdriver_--text/)
|
||||
|
||||
> Duplicate of [[--get_option_for_diffdriver]], so closing [[done]]. --[[Joey]]
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
It would be nice to be able to upload and download git history with special remotes. This could be a move towards full special remote syncing.
|
||||
|
||||
> I feel this is out of scope. git has its own interface to let a program
|
||||
> be registered as performing a transport, to store a git repository
|
||||
> anywhere. [[wontfix|done]] --[[Joey]]
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
Hi joey,
|
||||
|
||||
Currently, getting a useful diff between annexed file versions is quite involved [(setting up git-annex diffdriver)](https://git-annex.branchable.com/forum/git-like_git-annex_diff/).
|
||||
|
||||
It would be very nice if showing changes between annexed files was a little more straight-forward and ideally without any user config needed. UI suggestions:
|
||||
|
||||
- `git annex diff`: would behave exactly like `git diff`, but operatign on both unannexed and annexed contents
|
||||
- ideally re-implementing all its options (e.g. `--word-diff`, `--word-diff-regex`, etc.)
|
||||
- would need a diff implementation in Haskell (surely there is one)
|
||||
- sounds complicated to do TBH
|
||||
- Teaching `git diff` to use the annexed content instead of the pointer links/files
|
||||
- software like [`nbstripout`](https://github.com/kynan/nbstripout) passes the git-tracked contents through a filter before diffing. This sounds like git-annex could do the same to add straight-forward `git diff` support without user configuration.
|
||||
- git-annex already has a `* filter=annex` attribute in place, for text diffing there apparently needs to be a `* diff=annex` attribute and a `[diff "annex"] textconv=git-annex-output-content-instead-of-pointer` config.
|
||||
- even if the above works, I don't know how to temporarily switch this off without uncommenting the `textconv` e.g. with `git config --edit`. Sometimes you just want to see the actual hashes of old and new file.
|
||||
|
||||
Maybe `git annex diffdriver` kind of does part of this, but I don't really understand what it actually does.
|
||||
|
||||
Here other posts related to diffing:
|
||||
|
||||
- https://git-annex.branchable.com/forum/enabling_git-annex-diffdriver_for_gitk/
|
||||
- https://git-annex.branchable.com/todo/--get_option_for_diffdriver/
|
||||
|
||||
What do you think?
|
||||
|
||||
Cheers, Yann
|
||||
|
||||
PS: Thank you very much for git-annex, it's awesome! I'm giving a git-annex workshop next weekend [@Tuebix](https://cfp.tuebix.org/tuebix-2023/talk/review/GWRP3UKE3VFKVDG8RNQ8ZZPCZPNZYYWM), really looking forward to it.
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2023-06-28T17:43:19Z"
|
||||
content="""
|
||||
This works:
|
||||
|
||||
echo * diff=text >>.gitattributes
|
||||
git config diff.text.command "git-annex diffdriver -- sh -c 'echo diff a/\$0 b/\$0; echo \$0; diff -u \$1 \$4 || true' --"
|
||||
|
||||
Unfortunatly, the textconv approach will not work for locked files, because
|
||||
git does not apply the textconv to symlinks. It could be made to work for
|
||||
unlocked files but the above works for all annexed files.
|
||||
|
||||
diffing like this is only useful on text files, and most annexed files
|
||||
are not text files. That's why the diffdriver command focuses on using some
|
||||
external diff driver that knows how to diff whatever type of binary file is
|
||||
being stored in git-annex. So this should certianly not be enabled by
|
||||
default. It makes sense to enable it in .gitattributes when you have
|
||||
annexed some textual files.
|
||||
|
||||
That command is a bit hard to come up with, with the complex shell quoting.
|
||||
So rather than try to document it, I made an easier way to do the same
|
||||
thing:
|
||||
|
||||
echo * diff=text >>.gitattributes
|
||||
git config diff.text.command "git annex diffdriver --text"
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="Awesome, thanks!"
|
||||
date="2023-06-28T21:09:50Z"
|
||||
content="""
|
||||
Awesome, thanks joey!
|
||||
"""]]
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
Hi there,
|
||||
|
||||
I'm a relatively new to `git-annex` and quite impressed so far.
|
||||
|
||||
I've found the command to be somewhat less self-documenting than I'd like it to be for a new user.
|
||||
Particularly, since it's a `git` subcommand, I'd wish for annex to 'mirror' as many subcommands as possible
|
||||
with `annex`-enabled equivalents. My chief complaint at the moment is that it is a bit hard to remember the
|
||||
specific commands for showing remotes (`git annex info` has no equivalent `git info`) and `git annex remote`
|
||||
should ideally return a list of remotes for parallelism.
|
||||
|
||||
Similarly, it'd be nice if some of the commands were a bit nested to match `git` semantics. This would increase discoverability:
|
||||
For instance, `git annex enableremote` -> `git annex remote enable` or `git annex renameremote -> git annex remote rename`. Then subcommands for dealing with remotes
|
||||
could be more easily summarized on a single page in the `git-annex-remote` section.
|
||||
|
||||
It's worth noting that such changes could happen alongside the current commands without a loss of functionality. Git core
|
||||
has recently gone through a similar process to simplify the semantics of some of its commands. I'd ask for such changes to be considered.
|
||||
|
||||
Daven
|
||||
|
||||
> [[wontfix|done]] at least for the listed things, for reasons explained
|
||||
> in my comment below. --[[Joey]]
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2023-01-16T17:16:54Z"
|
||||
content="""
|
||||
> `git annex info` has no equivalent `git info`
|
||||
|
||||
git-annex can't be limited to commands that happen to have equivilant git
|
||||
commands. `git annex drop` also has no equivilant in git, but is
|
||||
fundamental to git-annex.
|
||||
|
||||
If you're thinking of `git annex info` as equivilant to `git remote` in
|
||||
listing remotes, that does not consider everything the info command does.
|
||||
|
||||
> git annex remote should ideally return a list of remotes for parallelism
|
||||
|
||||
`git remote` lists all remotes including git-annex special remotes,
|
||||
so `git annex remote` would be unnecessary duplication.
|
||||
|
||||
> git annex renameremote -> git annex remote rename
|
||||
|
||||
This would encourage drawing a false equivilance with `git remote rename`.
|
||||
|
||||
I'm also not convinced that stacking subcommands 3 levels deep is a good
|
||||
idea. The user has to dig through every level to find something then.
|
||||
|
||||
There's also an intentional similarity in naming between `git annex init`
|
||||
and `git annex initremote`, which I think makes sense and helps users
|
||||
learn and remember the latter command after having first learned the former.
|
||||
And `enableremote` and `renameremote` then flow naturally from that.
|
||||
This is, IMHO, a more natural learning flow than searching for strained
|
||||
equivilances to `git remote` commands.
|
||||
|
||||
I do think that `git annex add` has a very good reason to parallel `git
|
||||
add`, and if there are other git-annnex commands that could directly
|
||||
parallel a git command like that and don't, that would be worth addressing.
|
||||
"""]]
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="daven.quinn@d0ed4e0e5e4462d9a74a5d5a8fbd1b17f85db13e"
|
||||
nickname="daven.quinn"
|
||||
avatar="http://cdn.libravatar.org/avatar/4811a26fff610f0c9668d183481a7158"
|
||||
subject="comment 1 response"
|
||||
date="2023-01-16T21:45:35Z"
|
||||
content="""
|
||||
Fair enough, I suppose. However, I think that feedback from early-stage users should be weighted highly, as we interact with \"onboarding\"/\"discoverability\" problems that eventually fade from being users' primary impediments to use.
|
||||
|
||||
> git-annex can't be limited to commands that happen to have equivalant git commands.
|
||||
|
||||
I'm not suggesting that all commands should have `git` equivalents. Instead, when a commonly used equivalent (or close relative) is available, the name should be mirrored to increase discoverability of common idioms.
|
||||
|
||||
|
||||
> This would encourage drawing a false equivilance with git remote rename.
|
||||
|
||||
I'm not quite sure why the equivalence would be false — yes, the commands do somewhat different things. But they both fundamentally rename a remote.
|
||||
|
||||
> searching for strained equivilances to git remote commands.
|
||||
|
||||
Again, I am not sure the equivalences are so strained. Users should not (and I think broadly won't) expect a git-annex subcommand to do exactly the same thing as a git equivalent. But semantic-level parallelism with git top-level commands, and adopting git's pattern of grouping like functionality into subcommands, could greatly improve discoverability. As it stands, the goals of *preventing confusion between similarly named functionality* and *allowing functionality to be easily found* are in tension.
|
||||
|
||||
Another way to frame my suggestion is to consider the layout of the `git-annex` command line help output. Right now, when seeking assistance, the user is presented with a long list of commands and has to hunt for related functionality (`renameremote`, `enableremote`, etc.) within it. In contrast, when I type `git remote --help`, I see all of the commands for managing remotes in a single, shorter output. It is another nesting level, true, but I think a help page entry of `remote - manages git-annex special remotes` would be easier to parse than the current output.
|
||||
|
||||
Anyway, I appreciate your work on this system and consideration of user feedback.
|
||||
|
||||
Regards,
|
||||
Daven
|
||||
"""]]
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
I think the assistant should have a delay before starting so it doesn't impact on the system boot performance.
|
||||
|
||||
I know this can be configured per user (I have it set to 5min), but I think 2min is a sane default.
|
||||
|
||||
I don't really know how to submit patches (I can't attach it), so I simply copy it here. It's trivial enough.
|
||||
|
||||
[[!format txt """
|
||||
From bc6b90ce333659bd2511eedd4ab9067241f73780 Mon Sep 17 00:00:00 2001
|
||||
From: =?UTF-8?q?Jon=20Ander=20Pe=C3=B1alba?= <jonander.penalba@gmail.com>
|
||||
Date: Wed, 28 Oct 2015 12:00:51 +0100
|
||||
Subject: [PATCH] When autostarting the assistant on boot delay the execution
|
||||
2min
|
||||
|
||||
---
|
||||
Assistant/Install/AutoStart.hs | 2 +-
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
|
||||
diff --git a/Assistant/Install/AutoStart.hs b/Assistant/Install/AutoStart.hs
|
||||
index 5745030..6a09c3a 100644
|
||||
--- a/Assistant/Install/AutoStart.hs
|
||||
+++ b/Assistant/Install/AutoStart.hs
|
||||
@@ -35,6 +35,6 @@ fdoAutostart command = genDesktopEntry
|
||||
"Git Annex Assistant"
|
||||
"Autostart"
|
||||
False
|
||||
- (command ++ " assistant --autostart")
|
||||
+ (command ++ " assistant --autostart --startdelay=120")
|
||||
Nothing
|
||||
[]
|
||||
--
|
||||
2.6.2
|
||||
|
||||
|
||||
"""]]
|
||||
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2015-11-02T15:14:20Z"
|
||||
content="""
|
||||
There's actually an undocumented default startdelay of 5 seconds when using
|
||||
autostart. I've now documented it.
|
||||
|
||||
Maybe 5 seconds is too little. OTOH, 2 minutes may be a bit too much;
|
||||
if the user is booting up their computer to access a new file in their
|
||||
annex they'd expect it to start syncing ASAP.
|
||||
|
||||
I think my justification for the 5 seconds default was that about how long
|
||||
it seems to take a typical desktop system to get loaded (after the login
|
||||
screen) and for the user to open a web browser, on reasonably modern
|
||||
hardware. Even windows in an emulator doesn't take much longer than that.
|
||||
"""]]
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
It would be nice if a couple of additional environment variables to be set for hook uses.
|
||||
|
||||
In particular:
|
||||
|
||||
GIT_ANNEX_DIRECT=`git config annex.direct`
|
||||
|
||||
and
|
||||
|
||||
GIT_TOP_LEVEL=`git rev-parse --show-toplevel`
|
||||
|
||||
|
||||
I've made some changes to flickrannex to allow the sub-directories above the uploaded image to be added as tags. This change has been merged into trunk: [[https://github.com/TobiasTheViking/flickrannex]]
|
||||
|
||||
What I needed was both the environment variables mentioned above. One is set as part of the annex-hook and the other I guestimate from the file path. If it was set in git-annex it would be much cleaner (and accurate). So...I think this info would be useful for other hook.
|
||||
|
||||
> I think this was referring to the old hook special remote. External
|
||||
> special remotes have supplanted that. And when using an external special
|
||||
> remote you can query for such data once when starting your special remote
|
||||
> program, so no need for git-annex to do it. [[wontfix|done]] --[[Joey]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.154"
|
||||
subject="comment 1"
|
||||
date="2014-03-18T19:36:08Z"
|
||||
content="""
|
||||
Is this still relevant?
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
In certain situations different client annexes might get the same remote repository added, but before being synced.
|
||||
|
||||
Once the two clients sync they will both have two remotes with the same name. But only one UUID will have any content(Assuming only one client pushed).
|
||||
|
||||
It would be nice to have some (automatic?) way to resolve this conflict.
|
||||
|
||||
Not sure if anything sane can be done if both clients have pushed?
|
||||
|
||||
> [[done]] see comment --[[Joey]]
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2023-01-16T17:54:51Z"
|
||||
content="""
|
||||
This does not make sense to me. If the remote is a git repo,
|
||||
it will be initialized by git-annex only once, so there will only be one
|
||||
UUID. The second "client" that uses that remote will see the earlier UUID.
|
||||
|
||||
Unless there were some kind of a race in initializing the same repo
|
||||
concurrently, but that seems unlikely and if so this is lacking in any
|
||||
details about it.
|
||||
|
||||
I'm going to close this since it does not make sense, but do followup if
|
||||
you remember what this was supposed to be about.
|
||||
"""]]
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
```
|
||||
From 1a67bc14aa74262a304e7b6bd6372b0eca40486e Mon Sep 17 00:00:00 2001
|
||||
From: Reiko Asakura <asakurareiko@protonmail.ch>
|
||||
Date: Fri, 30 Sep 2022 10:56:17 -0400
|
||||
Subject: [PATCH] Fix annex.adviceNoSshCaching having no effect
|
||||
|
||||
git will always return option names in lowercase
|
||||
---
|
||||
Types/GitConfig.hs | 2 +-
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
|
||||
diff --git a/Types/GitConfig.hs b/Types/GitConfig.hs
|
||||
index 44629d412..4b892bd5f 100644
|
||||
--- a/Types/GitConfig.hs
|
||||
+++ b/Types/GitConfig.hs
|
||||
@@ -265,7 +265,7 @@ extractGitConfig configsource r = GitConfig
|
||||
| otherwise = Nothing
|
||||
in mapMaybe get (M.toList (Git.config r))
|
||||
]
|
||||
- , annexAdviceNoSshCaching = getbool (annexConfig "adviceNoSshCaching") True
|
||||
+ , annexAdviceNoSshCaching = getbool (annexConfig "advicenosshcaching") True
|
||||
}
|
||||
where
|
||||
getbool k d = fromMaybe d $ getmaybebool k
|
||||
--
|
||||
2.30.2
|
||||
|
||||
```
|
||||
|
||||
> Thanks for the fix! [[done]] --[[Joey]]
|
||||
|
|
@ -1,76 +0,0 @@
|
|||
This patch allows hooks to be run in WSL1 for a repo created on an NTFS volume but I think it also applies in general.
|
||||
|
||||
```
|
||||
From d4587806d8fd1ea767a8effc06edc1a4e10f5bca Mon Sep 17 00:00:00 2001
|
||||
From: Reiko Asakura <asakurareiko@protonmail.ch>
|
||||
Date: Sun, 25 Sep 2022 15:21:24 -0400
|
||||
Subject: [PATCH] Run freeze and thaw hooks on crippled filesystems
|
||||
|
||||
The user sets these hooks deliberately so they should always be run. For
|
||||
example this allows hooks to be used to manage file permissions on NTFS
|
||||
volumes in WSL1.
|
||||
---
|
||||
Annex/Perms.hs | 14 +++++++-------
|
||||
1 file changed, 7 insertions(+), 7 deletions(-)
|
||||
|
||||
diff --git a/Annex/Perms.hs b/Annex/Perms.hs
|
||||
index 6681da7e0..69e344452 100644
|
||||
--- a/Annex/Perms.hs
|
||||
+++ b/Annex/Perms.hs
|
||||
@@ -154,7 +154,7 @@ createWorkTreeDirectory dir = do
|
||||
- that happens with write permissions.
|
||||
-}
|
||||
freezeContent :: RawFilePath -> Annex ()
|
||||
-freezeContent file = unlessM crippledFileSystem $
|
||||
+freezeContent file =
|
||||
withShared $ \sr -> freezeContent' sr file
|
||||
|
||||
freezeContent' :: SharedRepository -> RawFilePath -> Annex ()
|
||||
@@ -163,7 +163,7 @@ freezeContent' sr file = freezeContent'' sr file =<< getVersion
|
||||
freezeContent'' :: SharedRepository -> RawFilePath -> Maybe RepoVersion -> Annex ()
|
||||
freezeContent'' sr file rv = do
|
||||
fastDebug "Annex.Perms" ("freezing content " ++ fromRawFilePath file)
|
||||
- go sr
|
||||
+ unlessM crippledFileSystem $ go sr
|
||||
freezeHook file
|
||||
where
|
||||
go GroupShared = if versionNeedsWritableContentFiles rv
|
||||
@@ -253,7 +253,7 @@ thawContent' sr file = do
|
||||
- permissions. -}
|
||||
thawPerms :: Annex () -> Annex () -> Annex ()
|
||||
thawPerms a hook = ifM crippledFileSystem
|
||||
- ( void (tryNonAsync a)
|
||||
+ ( hook >> void (tryNonAsync a)
|
||||
, hook >> a
|
||||
)
|
||||
|
||||
@@ -263,9 +263,9 @@ thawPerms a hook = ifM crippledFileSystem
|
||||
- file.
|
||||
-}
|
||||
freezeContentDir :: RawFilePath -> Annex ()
|
||||
-freezeContentDir file = unlessM crippledFileSystem $ do
|
||||
+freezeContentDir file = do
|
||||
fastDebug "Annex.Perms" ("freezing content directory " ++ fromRawFilePath dir)
|
||||
- withShared go
|
||||
+ unlessM crippledFileSystem $ withShared go
|
||||
freezeHook dir
|
||||
where
|
||||
dir = parentDir file
|
||||
@@ -287,9 +287,9 @@ createContentDir dest = do
|
||||
unlessM (liftIO $ R.doesPathExist dir) $
|
||||
createAnnexDirectory dir
|
||||
-- might have already existed with restricted perms
|
||||
- unlessM crippledFileSystem $ do
|
||||
+ do
|
||||
thawHook dir
|
||||
- liftIO $ allowWrite dir
|
||||
+ unlessM crippledFileSystem $ liftIO $ allowWrite dir
|
||||
where
|
||||
dir = parentDir dest
|
||||
|
||||
--
|
||||
2.30.2
|
||||
|
||||
```
|
||||
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2022-09-26T17:01:33Z"
|
||||
content="""
|
||||
Thank you for this patch. I've applied it.
|
||||
"""]]
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Simple "drop" have it, but no for "dropunused". Missed?
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nobodyinperson"
|
||||
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||
subject="git annex drop --unused --jobs=cpus works"
|
||||
date="2023-07-15T05:53:43Z"
|
||||
content="""
|
||||
If you want to drop all unused files, `git annex unused;git annex drop --unused --jobs=cpus` works.
|
||||
"""]]
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
Please add the feature/switch `--json-progress` to `git annex fsck --json`.
|
||||
|
||||
For a basic version, it would be nice to show the percentage using the number of processed chunks / total number of chunks for a given file while calculating checksum.
|
||||
|
||||
Let's not forget that a file on a remote can be fsck-ed when using `--from <remote>`. In this case if the file is not present locally, the file must be downloaded first (`--json-progress` is already supported for `get`). Usually this takes much-much longer as the checksum calculation. When checking a large file (~1Gb) on a not too fast remote, it's quite a time for the first "response" that something is happening when using the `--json` switch. To be exact, the first and only response is that the check has finished (happy way). It would be nice to see the json progress of the download+checksum calculation.
|
||||
|
||||
|
||||
Test environment:
|
||||
|
||||
Docker Community 20.10.5
|
||||
|
||||
Ubuntu 20.04.2 LTS (Focal Fossa)
|
||||
|
||||
git-annex version: 8.20210224-gf951847c6 (kitenet: SHA256E-s51232145--1e57d2e334cffdb3c3874785cfba4f6d5fc521808d0b1deef4fb68160dd88d48.tar.gz)
|
||||
|
||||
> [[done]] via incremental checksum while downloading, for nearly all
|
||||
> remotes. --[[Joey]]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="parhuzamos"
|
||||
avatar="http://cdn.libravatar.org/avatar/79ed445f40e89bd8ba696bab3942ec56"
|
||||
subject="comment 1"
|
||||
date="2021-05-24T09:33:50Z"
|
||||
content="""
|
||||
Is this possible? Or makes no sense? Do you plan implementing this?
|
||||
|
||||
Thank you,
|
||||
Bence
|
||||
"""]]
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2022-06-28T17:00:33Z"
|
||||
content="""
|
||||
It seems problimatic to have json progress for both downloading the file
|
||||
and for checksumming it. I don't know how that json would look.
|
||||
|
||||
In the meantime, though, git-annex has changed to checksum files while they
|
||||
are being downloaded from most remotes, and when it can do that, fsck
|
||||
--from avoids the separate checksumming step.
|
||||
|
||||
While some special remotes do not support that, it's a very limited list:
|
||||
only bittorrent on linux, and adb, external, gcrypt, hook, and rsync on
|
||||
other OSs.
|
||||
|
||||
This makes me think that complicating the json output to display two
|
||||
different kinds of progress is probably not worth the complication.
|
||||
"""]]
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="jstritch"
|
||||
avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
|
||||
subject="comment 3"
|
||||
date="2023-07-11T18:56:39Z"
|
||||
content="""
|
||||
The --json-progress flag should produce progress. I do not understand why it would be a problem to intermix types of 'action' in the output. If file A is uploaded and file B is downloaded and checksummed, that's (at least) three different progress objects to produce. This is exactly the type of information I want to see on the screen instead of wondering if it's stuck. I would also apply this pattern to sync and friends.
|
||||
|
||||
Upload A 35%
|
||||
|
||||
Upload A 100%
|
||||
|
||||
Download B 100%
|
||||
|
||||
Checksum B 50%
|
||||
|
||||
Checksum B 100%
|
||||
|
||||
Go ahead and make per-file json error results available and describe in the documentation.
|
||||
"""]]
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Add an armel build like the i386ancient build.
|
||||
|
||||
> [[wontfix|done]] --[[Joey]]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="rustikus@9db90d0c115a1825e2f1e5f15257ec1298a6c7b6"
|
||||
nickname="rustikus"
|
||||
avatar="http://cdn.libravatar.org/avatar/6fe372a7a46198829723c408af75c8cc"
|
||||
subject="Any update or help needed?"
|
||||
date="2017-01-12T13:40:38Z"
|
||||
content="""
|
||||
Hi,
|
||||
|
||||
is there any update? I do have an older version of Synology DiskStation (DS211+) which does have this CPU. Anything I can do to help?
|
||||
Disclaimer: I am quite familiar with Linux but I am no expert in programming with haskel.
|
||||
|
||||
Thanks!
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://schnouki.net/"
|
||||
nickname="Schnouki"
|
||||
avatar="http://cdn.libravatar.org/avatar/5f6406e9db28564121169f0051645b8c30a12a20ca7bc40287ac9bf2cd3ad283"
|
||||
subject="comment 2"
|
||||
date="2017-02-02T22:05:23Z"
|
||||
content="""
|
||||
+1. Can't upgrade the kernel on my NAS (Synology DS413j, running Linux 2.6.32...), so I'm stuck with git-annex 5.20150731...
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2017-02-20T16:22:58Z"
|
||||
content="""
|
||||
The build is set up; it's not run to completion yet, but fingers crossed it
|
||||
will eventually.
|
||||
"""]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2018-10-03T16:58:26Z"
|
||||
content="""
|
||||
Unfortunately the build failed in an obscure way while installing the deps
|
||||
of git-annex back when I tried to set it up.
|
||||
|
||||
I tried it again today, and there's no longer a binary of stack for armel,
|
||||
only for armhf, so I don't think this build can be provided, at least not
|
||||
without quite a lot of backporting.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
I have a bunch of files I want to track with `git-annex` that are sitting in an external drive. I have a repository sitting on my laptop, but I don't actually have enough free disk space on my laptop to import the files. Really, I just want the file content to be sitting in a special remote. I was thinking the following workflow could be useful:
|
||||
|
||||
cd ~/my-laptop-repo
|
||||
git-annex import --to=s3-remote /mnt/usb-drive/myfiles
|
||||
|
||||
The proposed `--to=remote` option would add the files to my repo as `import` normally does, but it wouldn't every keep the content in the repo, the only copy would now sit in `s3-remote`. As little disk space as possible would be staged temporarily in `~/my-laptop-repo`. Perhaps the easiest option would be to import a file normally, but them immediately do a `move` to `s3-remote`? But, ideally for larger files, we would want to stream them directly from `/mnt/usb-drive/myfiles` to `s3-remote` without ever staging them at `~/my-laptop-repo`.
|
||||
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="comment 1"
|
||||
date="2019-01-14T16:11:39Z"
|
||||
content="""
|
||||
Cf. [[todo/import_tree]].
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
|
||||
nickname="lykos"
|
||||
avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
|
||||
subject="comment 2"
|
||||
date="2019-01-21T11:57:07Z"
|
||||
content="""
|
||||
Import tree won't help here. Actually I've got the same problem on one of my machines. I'm currently using a script that imports a bunch of files and moves them to the remote, then imports some more files and so on. It's quite cumbersome, to be honest. So yes, I'd appreciate `git annex import --to <remote>` as well. (Same with `git annex move --from remote-a --to remote-b` actually.)
|
||||
"""]]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2019-01-22T15:39:49Z"
|
||||
content="""
|
||||
Import tree + move --from --to would be equivilant functionality to import --to.
|
||||
The directory you want to import "to" would be set up as a directory
|
||||
special remote and import tree used on it.
|
||||
|
||||
However, it seems to me that if I wanted to accomplish this today, I'd
|
||||
simply make a clone of my git-annex repository onto the external drive,
|
||||
move the files I want into that clone (a cheap operation as it's the same
|
||||
drive), and `git annex copy --to s3-remote`
|
||||
"""]]
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2019-11-19T16:58:06Z"
|
||||
content="""
|
||||
Since git-annex does now support importtree from directory special remotes,
|
||||
you can almost get what you said you want by:
|
||||
|
||||
git annex initremote usb-drive type=directory directory=/mnt/usb-drive/myfiles \
|
||||
exporttree=yes importtree=yes encryption=none
|
||||
|
||||
Then `git annex import master --from usb-drive` will import the files
|
||||
into a usb-drive/master branch that you can merge. And you can run it
|
||||
repeatedly to import new and changed files from the directory.
|
||||
|
||||
So then you have the files sitting in a special remote like you wanted.
|
||||
Namely the directory special remote on the USB drive. Only problem is that
|
||||
importing the files does also copy them into the git-annex repo. So you'd
|
||||
have to drop the files again, assuming you had disk space for them all
|
||||
to begin with.
|
||||
|
||||
I wonder, if it were possible to import the files without add their content
|
||||
to the repo you ran the import from, leaving them on the special remote,
|
||||
would that meet your use case? That seems like something it would be
|
||||
possible to add.
|
||||
|
||||
It would still probably have to copy the file into the local repo, in order
|
||||
to hash it, and then just delete the content from the local repo. Of course
|
||||
when the file is in a directory on the local system, that's not strictly
|
||||
necessary; it could do the hashing of the file in place. But that would
|
||||
need an extension to the special remote API to hash a file.
|
||||
|
||||
But like I said in my other comment, I'd just clone my git-annex repo onto the
|
||||
drive and add the files to the repo there. Avoids all this complication.
|
||||
You'd need to provide a good justification for why you can't do that for
|
||||
me to pursue this any further.
|
||||
|
||||
(As far as adding a --to switch to import, [[transitive_transfers]]
|
||||
discusses this kind of thing, and some issues with implementing that.)
|
||||
"""]]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 5"""
|
||||
date="2023-06-23T16:38:50Z"
|
||||
content="""
|
||||
It's now possible to `git-annex import --no-content --from
|
||||
a-directory-special-remote`. So then you have the files sitting on the
|
||||
external drive and not filling up the git repository.
|
||||
|
||||
And `git-annex copy --from foo --to bar` is also supported, so you can
|
||||
use that to send the files over the S3 or wherever.
|
||||
|
||||
So, I think this todo can be closed.
|
||||
"""]]
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
Should `annex.gitaddtoannex` and `annex.addsmallfiles` be [[`git-annex-config`|git-annex-config]] settings, given that `annex.largefiles`, `annex.dotfiles` and `annex.addunlocked` already are?
|
||||
Also, [maybe](https://git-annex.branchable.com/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/#comment-85cb4d3eac345df7b08a31ea4bd810f6) make `annex.supportunlocked` a `git-annex-config` setting as well.
|
||||
|
||||
|
||||
> [[rejected|done]] --[[Joey]]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://christian.amsuess.com/chrysn"
|
||||
nickname="chrysn"
|
||||
avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
|
||||
subject="+1 on supportunlocked in git-annex config"
|
||||
date="2021-07-09T15:25:53Z"
|
||||
content="""
|
||||
supportunlocked would definitely make sense; it can help protect against users accidentally checking in a file in the wrong mode even though it doesn't fit the repo's workflows.
|
||||
|
||||
The alternative to setting this across all repos using git-annex config, at least in my workflows, would be to set a git hook to reject pushes (to master or synced/master) that contain unlocked files, but that sounds way more complex.
|
||||
"""]]
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue