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

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

Browse source
This commit is contained in:
Joey Hess 2023-02-23 14:40:38 -04:00
commit 35f37ecb9a
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 49 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_3_5b2956522ce9c9cdc0c704e63efe8dac._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="hurlebouc"
avatar="http://cdn.libravatar.org/avatar/bda734a6d937c1fe0c9778a6eaefffbc"
subject="comment 3"
date="2023-02-21T06:49:27Z"
content="""
Hi,
Any idea explainig this failure?
"""]]

24
doc/todo/View_for_old_versions_of_a_file.mdwn Normal file
View file

@ -0,0 +1,24 @@
Hey joey,
I often find myself wanting to compare older versions of files (plots, images, etc...) and currently browse the git history and copy-paste paths to the old files in the `.git/annex/objects` to open them or launch a diffing program. This works, but is quite tedious.
I see there is [`git annex diffdriver`](https://git-annex.branchable.com/git-annex-diffdriver/), but haven't tried it yet.
Wouldn't a **view showing old versions of files** be nice? I haven't thought this through fully, but I think this could be implemented similar to the `/=foo` or `/foo=bar` original path filtering logic by introducing a new virtual metadata field (maybe `:`? or `^` like ”anchor”/”history”? 🤔 Aren't that many ASCII characters without special shell meaning left that aren't allowed in a field name... 😅) where old versions of files get assigned that `^` field with their own path or filename and the view would just use the filename as folder level like any other field.
Or a `git annex view --historical` could be added that allows for scanning the entire history (or up to a certain reach into the past) to include old files as well and adds a git commit identifier to the filename to avoid conflicts.
[[!format bash """
# show all versions of files tagged with 'plot' in the foo directory
git annex view --historical tag=plot /=foo
# This would then make a folder structure like
"""]]
Not only would this facilitate easy history browsing, but also a more visual way of (force) dropping old content selectively - especially with graphical tools like my Thunar plugin (switch into historical view, select and right-click unneeded files, drop).
What do you think?
Thanks again for git-annex, It's amazing! 🥳
Yann

15
doc/todo/reuse_desktop_notifications/comment_2_3fb10a432a57ce14cb7bc2946467ab22._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
subject="comment 2"
date="2023-02-23T08:59:28Z"
content="""
I think perhaps the notify options should be revamped as I don't get what their purpose is.
Receiving one desktop notification for each and every transfer sounds like insanity to me. I'd get constant notifications doing anything at all.
To me, notifications are for things that require immediate attention. An email for example or an assistant fsck that found corrupted files or perhaps a failed git-annex transfer. That sort of thing.
What's the use-case of constantly requiring immediate attention the entire time for every benign thing happening? In my mind, I might as well just watch the git-annex progress log at that point.
Before reading what the options actually did, I would have expected `--notify-finish` to produce exactly one notification when the git-annex command I set off is done. Perhaps with a summary in it what it had done (successes/errors).
"""]]