update

checked getKeysPresent; it's ok for v6 unlocked files

When a v6 unlocked files is removed from the work tree,
unused doesn't show it. When it gets removed from the index,
unused does show it. This is the same as a locked file.

fsck for v6 unlocked files

This only adds 1 stat to each file fscked for locked files, so
added overhead is minimal.

For unlocked files it has to access the database to see if a file
is modified.

finish v6 git-annex lock

This was a doozy!

only make 1 hardlink max between pointer file and annex object

If multiple files point to the same annex object, the user may want to
modify them independently, so don't use a hard link.

Also, check diskreserve when copying.

Merge branch 'master' into smudge

fsck: Failed to honor annex.diskreserve when checking a remote.

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

webdav: When testing the WebDAV server, send a file with content. The empty file it was sending tickled bugs in some php WebDAV server.

comment

comment

comment

add Blackblaze B2 extranal special remote to the list

comment

clean up

wip

Added a comment

v6 git-annex unlock

Note that the implementation uses replaceFile, so that the actual
replacement of the work tree file is atomic. This seems a good property to
have!

It would be possible for unlock in v6 mode to be run on files that do not
have their content present. However, that would be a behavior change from
before, and I don't see any immediate need to support it, so I didn't
implement it.

add generalized linkAnnex'

always format pointer file with a trailing newline

Before the smudge filter added a trailing newline, but other things that
wrote formatPointer to a file did not.

also some new pointer staging code to use later

Added a comment

todo

check InodeCache in inAnnex et al

This avoids querying the database when the content file doen't exist
(or otherwise fails the provided check). However, it does add overhead of
querying the database, and will certianly impact performance.

check inode cache in prepSendAnnex

This does mean one query of the database every time an object is sent.
May impact performance.

move

Merge branch 'master' into smudge

comment

Added a comment: Complete removal

Add S3 features to git-annex version output.

comment

response

response

Added a comment: The downside

make clear when code is using deprecated direct mode files

reorder

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

devblog

Merge branch 'master' into smudge

use InodeCache when dropping a key to see if a pointer file can be safely reset

The Keys database can hold multiple inode caches for a given key. One for
the annex object, and one for each pointer file, which may not be hard
linked to it.

Inode caches for a key are recorded when its content is added to the annex,
but only if it has known pointer files. This is to avoid the overhead of
maintaining the database when not needed.

When the smudge filter outputs a file's content, the inode cache is not
updated, because git's smudge interface doesn't let us write the file. So,
dropping will fall back to doing an expensive verification then. Ideally,
git's interface would be improved, and then the inode cache could be
updated then too.

add inode cache to the db

Renamed the db to keys, since it is various info about a Keys.

Dropping a key will update its pointer files, as long as their content can
be verified to be unmodified. This falls back to checksum verification, but
I want it to use an InodeCache of the key, for speed. But, I have not made
anything populate that cache yet.

Added a comment

move InodeSentinal from direct mode code to its own module

Will be used outside of direct mode for v6 unlocked files, and is already
used outside of direct mode when adding files to annex.

link/copy pointer files to object content when it's added

avoid clean filter trying to annex a pointer file

avoid pre-commit hook messing up new-style unlocked files in v6 repo

stash DbHandle in Annex state

refactor and improve pointer file handling code

Added a comment: anyone saw/worked on backend for watchdox service? (not free one but needed :-/)

todo

add news item for git-annex 5.20151208

prep release

response

Added a comment: Problems initializing glacier remote

I started using a repo on S3, so that partially answered my question about how files are stored on S3.

Added a comment

Added a comment: How to view configuration of special remotes?

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

devblog

long walk led to long list of things to do

require "annex/objects/" before key in pointer files

This removes ambiguity, because while someone might have "WORM--foo" in a
file that's not intended to be a git-annex pointer file,
"annex/objects/WORM--foo" is less likely.

Also, 664cc987e806800ef46794f356003321170c1060 had a caveat about symlink
targets being parsed as pointer files, and now the same parser is used for
both.

I did not include any hash directories before the key in the pointer file,
as they're not needed. However, if they were included, the parser would
still work ok.

support pointer files

Backend.lookupFile is changed to always fall back to catKey when
operating on a file that's not a symlink.

catKey is changed to understand pointer files, as well as annex symlinks.

Before, catKey needed a file mode witness, to be sure it was looking at a
symlink. That was complicated stuff. Now, it doesn't actually care if a
file in git is a symlink or not; in either case asking git for the content
of the file will get the pointer to the key.

This does mean that git-annex will treat a link
foo -> WORM--bar as a git-annex file, and also treats
a regular file containing annex/objects/WORM--bar as a git-annex file.

Calling catKey could make git-annex commands need to do more work than
before. This would especially be the case if a repo contained many regular
files, and only a few annexed files, as now git-annex will need to ask
git about the contents of the regular files.

update associated files database on smudge and clean

associated files database

wording

Merge branch 'master' into smudge

Added a comment

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

fix temp filename

Was not putting it inside the temp dir, but next to it!

This was just wrong, and it led to a longer filename that desired being
used, leading to some bug reports.

avoid too long temp dir template

The filename might be at or close to the filename length limit, so using it
as the template for the temp dir would then fail.

cleanup

avoid looping trying to make temp dir when the name is too long

Only loop when directory creation fails due to the directory existing
already.

Added a comment

generalize catchHardwareFault to catchIOErrorType

Fix broken link to other bug

Report bug due to broken createSymbolicLink

m

Copy hints for Emacs users from propellor coding style page

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

devblog

init: Configure .git/info/attributes to use git-annex as a smudge filter.

Note that this changes the default behavior of git add in a newly
initialized repository; it will add files to the annex.

Don't like that this could break workflows, but it's necessary in order for
any pointer files in the repo to be handled by git-annex.

refactor

comments

don't let git-annex direct be run in a v6 repo

add v6; keep v5 working for now and manual upgrade

Since all places where a repo is used in direct mode need to have git-annex
upgraded before the repo can safely be converted to v6, the upgrade needs
to be manual for now.

I suppose that at some point I'll want to drop all the direct mode support
code. At that point, will stop supporting v5, and will need to auto-upgrade
any remaining v5 repos. If possible, I'd like to carry the direct mode
support for say, a year or so, to give people plenty of time to upgrade and
avoid disruption.

auto-configure filter.annex.smudge and clean on init

merge clean into smudge command

The git filter config can be used to map the single git-annex command to
the 2 actions, and this avoids "git annex clean" being used for this thing,
it might have a better use for that name later.

avoid unnecessary reading of git-annex branch data when matching on annex.largefiles

This makes git annex clean not look at the git-annex branch at all,
and so speeds it up by 50% or more.

clean filter should update location log when adding new content to annex

avoid commit and messages for smudge filter

annex.largefiles support for clean filter

smudge filter working

basic clean filter working

skeleton smudge/clean filters

Added a comment: Again, difficult to tell