Added a comment: gcrypt and map

Catch up with current git behavior when both repo and repo.git exist; it seems it now prefers repo in this case, although historically it may have preferred repo.git.

comment

enableremote: List uuids and descriptions of remotes that can be enabled, and accept either the uuid or the description in leu if the name.

response

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

respinse

emphasize that 32 bit version if git for windows is the one that works with git-annex

Added a comment: Replicating my key for encrypted special remotes

poll vote (/sdcard/annex)

Added a comment: oops

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

Changelog typo: remove, not remote

Added a comment

Symlink timestamp preservation code uses functions from unix-2.7.0 when available, which should be more portable.

trick question

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

update

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

Use statvfs on OSX.

Fixes a recent-ish build warning on about 64 bit vs non.

This is the method used by the disk-free-space library, and I tested it to
yield the same results on even 10 tb drives on OSX -- so it's getting 64
bit values.

Added a comment: happy birthday!

add link to new survey

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

Added a comment

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

devblog

Added a comment

2015 user survey

add news item for git-annex 5.20151019

roadmap update

Debian: Remote menu file, since a desktop file is provided and lintian says there can be only one.

prep release

remove verbose flag; aws deps fixed

response

comment

response

Added a comment

Added a comment

Added a comment

Added a comment: Replicating my key for encrypted special remotes

Added a comment

Added a comment: amazing

Added a comment

devblog

upstream patch needs testing

followup

close as encfs is the bug

fixed

Avoid displaying network transport warning when a ssh remote does not yet have an annex.uuid set.

Instead, only display transport error if the configlist output doesn't
include an annex.uuid line, even an empty one.

A recent change made git-annex init try to get all the remote uuids, and so
the transport error would be displayed by it. It was also displayed when
eg, copying files to a remote that had no uuid yet.

add a hint about syncing when unable to determine remote uuid

syncing gets the uuid in passing..

improve layout and comment

response

response

do tmp dir cleanup in error case too

close

avoid making post-merge-conflict-resolution commit when no conflicts were resolved

sync, merge, assistant: When git merge failed for a reason other than a
conflicted merge, such as a crippled filesystem not allowing particular
characters in filenames, git-annex would make a merge commit that could
omit such files or otherwise be bad. Fixed by aborting the whole merge
process when git merge fails for any reason other than a merge conflict.

analysis

comment

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

S3: Fix support for using https.

Was using the http-only Manager before, not the tls-capable one.

refactor

Added a comment

Added a comment: renaming oesn't work as expected when changing the extension

word wrap

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

Changed drop ordering when using git annex sync --content or the assistant, to drop from remotes first and from the local repo last. This works better with the behavior changes to drop in many cases.

timing info

fix various build warnings, mostly on Windows

And some when S3 is disabled

Added a comment

put Win32-extras in extra-deps as it's not yet in lts

more notes

workarounds

clarification

Added a comment

new bug

doc/devblog/day_322-326__concurrent_drop_safety.mdwn: Wording

comment typo

fix windows build

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

fix export list to work on windows

response

Avoid unncessary write to the location log when a file is unlocked and then added back with unchanged content.

Implemented with no additional overhead of compares etc.

This is safe to do for presence logs because of their locality of change;
a given repo's presence logs are only ever changed in that repo, or in a
repo that has just been actively changing the content of that repo.

So, we don't need to worry about a split-brain situation where there'd
be disagreement about the location of a key in a repo. And so, it's ok to
not update the timestamp when that's the only change that would be made
due to logging presence info.

Added a comment

comment