Recent comments posted to this site:

I also struggle with these issues on macOS.

One workaround would be to always use unlocked files,

git config annex.addunlocked true

The main disadvantage here is that you use double the disk space for every file. After switching to unlocked files you could then also switch to thin mode:

git config annex.thin true
git annex fix

Which would only keep 1 copy of every file (using hardlinks), so you are back down to a normal amount of disk space, but you give up some of the protections of git-annex since you could easily delete the only copy of your files.

I have verified that using unlocked files and using unlocked-thin both fix file names in Preview and mail attachments. I'm not sure if both these methods allow files to be indexed by Spotlight.

I have also been hoping to integrate many of these features into git-annex-turtle using the Search and Spotlight developer APIs. Namely Core Spotlight could be used to index all git-annex locked/unlocked/present/not-present files and Quick Look APIs could be used to allow previewing of not present files using cached thumbnails.


Comment by andrew Sun Mar 29 15:27:40 2020

Both suggestions solve my issue. Thank you for the quick reply!

Comment by Fri Mar 27 23:04:34 2020
I meant, unless annex.gitaddtoannex=false.
Comment by Ilya_Shlyakhter Fri Mar 27 21:12:18 2020
My "upgrade to most recent version" advice should have mentioned that the most recent version is 8., which will auto-upgrade your repositories to version 8. If for whatever reason you don't want to do the upgrade right now, 7. versions from 7.20191024 restore old behavior, as Kyle suggested. Note that if you have annex.largefiles configured, git add will add matching files to the annex, unless annex.gitaddtoannex.
Comment by Ilya_Shlyakhter Fri Mar 27 21:11:13 2020

git annex 7.20190912-1

The git add behavior that you describe changed in 7.20191024. The CHANGELOG entries under that release provide a good description of the current behavior.

Comment by kyle Fri Mar 27 20:49:44 2020
It's a change in default behavior, but the old default was restored in the more recent versions. (Detailed discussion here). Can you upgrade to the most recent version? conda lets you install one without being root. You might also want to set annex.gitaddtoannex to false.
Comment by Ilya_Shlyakhter Fri Mar 27 20:49:19 2020
Thanks for taking the time to review this patch and the add --force-small ones. Very much appreciated!
Comment by kyle Thu Mar 26 23:32:56 2020

When testing a new version of git-annex-remote-googledrive, I often use a wrapper script like this:

# .zshrc.local

f_git_annex () {
        log_file=$(mktemp "$(git rev-parse --git-dir 2>/dev/null)/annex/debug.XXX.log" 2>/dev/null)
        if [ $? -ne 0 ]; then
                echo "Error creating log file. Proceeding without logging."
                git annex $@
                return $?

        git annex $@ --debug 2> $log_file
        if [ $? -ne 0 ]; then
                echo "Errors occurred. Debug log in $log_file"
                return $?
                rm $log_file
alias ga='f_git_annex'

It's good enough for me in those cases. Changing the first line of the function to something like this log_file=$(umask 077; mktemp /tmp/annex.debug.XXX.log" 2>/dev/null) would help against accumulating logs.

Comment by lykos Thu Mar 26 20:36:28 2020

Ok, figured it out.. reverseAdjustedTree uses a propchanges function that looks at the diff from adjusted branch to basis, and substitutes the new sha for the old one. So that's how the sha get changed.

My analysis was otherwise correct, I think. And your patch is fine, now that I understand that. Applying it as-is.

Comment by joey Thu Mar 26 18:53:05 2020

Little bit of a scary change, because calls to adjustTree could be not handling the case of a submodule correctly in their adjusttreeitem function.

So I checked them all..

Command.Export uses adjustTree with an adjusttreeitem function that runs catKey on the sha from the TreeItem. I think that would be ok, because catKey will see it's not a key, and in that case it passes back the TreeItem unchanged.

Each different adjusted branch has its own function. Most of those check if the TreeItem is a symlink, with a submodule is not, and they'll return it unchanged.

The PresenceAdjustment instead uses catKey, and again looks ok, because it falls back to returning the TreeItem unchanged.

The LockAdjustment, when the TreeItem is not a symlink, also uses catKey, which will see it's not a key, and also falls back to returning the TreeItem unchanged.

Think that's everything, so this seems a safe change to make.

But.. I don't actually understand how your change fixes the problem!

(Of course, I tried your patch, and it does work...)

I've been staring at it for 30 minutes and it seems to me that the TreeItem you have it construct gets passed to adjusttreeitem, which always returns it unchanged (per analysis above). Then you deconstruct the TreeItem, extracting the file mode and sha, and construct a TreeCommit from those. As far as I can see, that TreeCommit must be identical to the one it constructed before this patch.

Hmm, so I added a debug print and it's not the same, the sha is different.

What am I missing?

Comment by joey Thu Mar 26 18:15:57 2020