Recent comments posted to this site:

comment 23 70dcb7e7ffdd14351adaf4c40ee7fdd0
[[!comment Error: unsupported page format hs]]
Wed May 11 16:41:58 2016

I don't know what needs to be put where in the app to make open run git-annex-webapp. There is already a Info.plist file that I thought was supposed to handle that. If someone wants to help make open work please be my guest.

Comment by joey Tue May 10 17:22:03 2016

Just downloaded the DMG, copied the .app into /Applications and ran it; does nothing, from terminal:

$ open -W /Applications/git-annex.app The application cannot be opened because its executable is missing.

$ /Applications/git-annex.app/Contents/MacOS/git-annex-webapp $ unable to start webapp in repository /Users/lhunath/annex: Not in a git repository. Launching web browser on file:///var/folders/np/v9byg9092bbf31jw5cydzszm0000gn/T/webapp1622650073984943658.html

$ /Applications/git-annex.app/Contents/MacOS/git-annex version git-annex version: 6.20160427-gd0036b9 build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external

Comment by lhunath Thu May 5 04:33:06 2016

@zpeters, the order that remotes are accessed are ordered by cost.

You can configure the costs of remotes by setting remote.$name.annex-cost to eg 100 to make it be checked first or 300 to make it be checked later.

There's also a remote.$name.annex-cost-command that runs a command to get the cost. You could perhaps use that to detect which network you're on and alter the costs appropriately.

Comment by joey Wed May 4 17:23:41 2016

I might have a unique situation but i have a git annex repo that has multiple remotes for the same actual location. I have a server at home and when i'm "out in the world" i use it's external IP and when i'm at home i use it's internal IP. It appears that when i do an git annex drop on my laptop to compares and locks whichever remote is alphabetically first.

What i'm wondering is is there a way to tell git annex which remote i want to compare against? For example when i'm remote i want to do something like "git annex drop . --compare remoteServer"

Thank you!

Comment by zpeters Tue May 3 23:37:09 2016

Both git annex sync and git pull will still try to access the git remote for the repository. Thing to do to prevent this is git remote remove it.

I think it makes sense for git annex sync to still try to push/pull from a dead remote, since git pull/push will still try to access it too. Marking the remote dead does prevent other git-annex commands from trying to use it for data storage.

Comment by joey Tue May 3 19:15:58 2016
Agreed, DIRHASH-LOWER is more consistent, changed it to that.
Comment by joey Tue May 3 18:09:50 2016

Thanks. It'll probably be safer for my use case of storing data on Windows network shares than the mixed-case version.

(Speaking of "too late to change", DIRHASH-LOWER with a dash might be more consistent with the existing responses?)

Comment by grawity Tue May 3 18:02:03 2016

I don't think there's any particularly good reason why DIRHASH uses the mixed case format. However, it can't be changed without busting existing stuff.

So yeah, I've gone ahead and added a DIRHASH_LOWER.

Comment by joey Tue May 3 17:29:02 2016

@grawity yes, enableremote is the way to change configuration of an existing special remote.

The special remote names are a bit funky; to keep the user from needing to enter in a long uuid when enabling a particular special remote, a name has to be recorded for the remote, and that becomes shared across clones of that repository, in a way that the names of git remotes are not normally. (Normally, my "origin" might be your "upstream" etc.)

While it could ignore dead remotes when initializing a new remote with an existing name, then if the old remote got brought back from the dead, there would be a naming conflict. So, I think it's best to not go down that path, to avoid the undead horrors lurking there. ;-)

Comment by joey Tue May 3 17:12:42 2016