magit / magit-annex Goto Github PK

All the other repositories in this organisation now do.

Hello,

We are running magit-annex's test suite on Debian's CI infrastructure. While the tests usually pass we have noticed that every so often a test fails with the following error:

(user-error "Not inside a Git repository")

A quick look at the logs shows this happening with several different of the ten ERT tests. Full logs are here (scroll down that page and look for "thumbs down" icons).

Please let me know if I can help debug. For now, I am disabling the test suite on our CI infrastructure. We already have it disabled during the package build process due to the same error.

I'm trying to get a worklfow were commits are automated with the help of the magit-post-stage-hook, with context-aware commits. However, this hook is not run when running git-annex-add on a file.

I believe it would make sense to support this hook when running git-annex-add, because it does indeed stage the git-annex symlink.

Hello,

I think the magit-annex-unlock-lock-files test needs to be updated for the way that unlocked files work in v7 git-annex repos (which is the new default).

The fourth line of the test, (should-not (magit-annex-unlocked-files)), fails because committing changes to an unlocked file no longer locks it.

Thanks!

This could be useful for restructuring the dir structures.

In the case of a file with [ in its name, it is treated as a wildcard, expanded and then doesn't match the actual file, so we get nil.

In the case of a file with a comma in its name, completing-read-multiple treats each such file name as multiple files because it splits on the comma, and then git-annex fails to find the files.

I have PRs to make for each case if you'd like.

Unused mode doesn't account for partially transferred files.

  Some annexed data is no longer used by any files:
    NUMBER  KEY
    1       SHA256E-s11--672ee719586ff07b9dec8d03e5449afacc694c3f567b98a98ee96d5a7eb91cf2
  (To see where data was previously used, try: git log --stat -S'KEY')

  To remove unwanted data: git-annex dropunused NUMBER


  Some partially transferred data exists in temporary files:
    NUMBER  KEY
    2       SHA256E-s22392746240--d4def8352bdc25a8149a7d912c98cb967beafc275667691703be691e4ae41d34.h5

  To remove unwanted data: git-annex dropunused NUMBER

[Related to git-annex/Emacs, but not directly related to Magit-annex]

I've started working on a project (annexview) that may be of interest to many Magit-annex users. It provides Dired support for modifying git-annex metadata and creating views. At the moment, it's available through the repo only, but I'll submit it to ELPA at some point.

@l can be pretty slow. Even on a modestly large repository, it takes longer than tolerable. In my use case, I want to browse a repository and see which files are present and which are not, and "get" some of those files. The way things work right now, it can take more than a minute. In a offhand test, it seems to take 80 seconds to list a 6500 files repository. Yet listing the files with only git-annex is much, much faster:

$ time sh -c 'git annex find --include "*" | wc -l'
6551
0.38user 0.04system 0:00.40elapsed 105%CPU (0avgtext+0avgdata 51916maxresident)k
0inputs+0outputs (0major+3300minor)pagefaults 0swaps

That's 400 miliseconds, 200 times faster. I thought at first it was because magit-annex was using list instead, but it doesn't seem to be the case:

$ time sh -c 'git annex list | wc -l'
6559
7.98user 1.08system 0:08.27elapsed 109%CPU (0avgtext+0avgdata 37332maxresident)k
0inputs+0outputs (0major+41074minor)pagefaults 0swaps

Still a good 10 times faster. So something fishy is happening when listing the files...

I am not sure how to fix this. From reading the source code, there should be a list-specific popup that would allow me to restrict the list to a subdirectory. This would help, but I can't figure out how to trigger that. Doing @l triggers the full list. Calling M-x magit-annex-list-popup also creates a full list.

Fundamentally, there's something inefficient in the way magit-annex lists files that makes it difficult to use. It would be great to have a smoother operation there, as there are very few interfactive interfaces to operate on git-annex files on Linux platforms. Mac OS X has the incredible git-annex-turtle but there's nothing even remotely ressembling this in Linux...

Thanks!

The Forge extension for Magit also uses @ as a default prefix. magit-annex is certainly older, and keeping consistent with the dired extension seems desirable. On the other hand, Forge is fairly popular these days, and it would be nice for magit-annex not to conflict with it out of the box.

Of course, users can rebind the magit-annex prefix if they want. But what do you think about changing the default prefix to accomodate Forge? Feel free to close this issue if you think maintaining consistency for existing users takes precedence, but maybe a note with a suggested override config could be added to the package frontmatter, or the hardcoded @ autoload could be changed to use a custom variable?

Hello,
when trying to execute @ : = Annex subcommand (from pwd) the following error occurs:

Debugger entered--Lisp error: (wrong-number-of-arguments (1 . 1) 2)
 magit-git-command("annex info" "/some_path/")
apply(magit-git-command ("annex info" "/some_path/"))
magit-annex-command()
funcall-interactively(magit-annex-command)
....

Somebody might have overseen to adjust the apply command.