| Commit message (Collapse) | Author | Age |
|
|
|
| |
intialized by git-annex.
|
|
|
|
|
|
|
|
|
|
|
|
| |
the same repository, honor remote cost settings and use the cheapest available.
Note that TransferInfo does not always contain the Remote, although
any transfer added to the TransferQueue does have a Remote in its
TransferInfo. The transferkeys command still accepts a UUID, which is
useful to handle upgrades, where an old assistant version runs the new
transferkeys.
This commit was sponsored by Kalle Svensson.
|
| |
|
|
|
|
|
|
|
|
| |
It is useful to be able to specify an alternative git-annex-shell
program to execute on the remote, e.g., to run a version not on the
PATH. Use remote.<name>.annex-shell if specified, instead of the
default "git-annex-shell" i.e., first so-named executable on the
PATH.
|
|
|
|
| |
repository.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Only fsck and reinject and the test suite used the Backend, and they can
look it up as needed from the Key. This simplifies the code and also speeds
it up.
There is a small behavior change here. Before, all commands would warn when
acting on an annexed file with an unknown backend. Now, only fsck and
reinject show that warning.
|
|
|
|
| |
~/.config/git-annex/autostart but no longer has a git repository in it.
|
|
|
|
| |
count.
|
|
|
|
| |
configuration of a previously known repository. Useful if a repository got deleted and you want to clone it back the way it was.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To do so, I slightly changed the behavior of unannex. Now in fast mode, it
only makes a hard link when the annexed file's link count is 1. This avoids
unannexing 2 files with the same content in fast mode from hard linking
them together. (One will end up hard linked to the annex, which the docs
warn about.)
With that change, uninit can simply always run unannex in fast mode. Since
.git/annex/objects is being blown away anyway, there's no worry in this
case about a hard link pointing into it causing an annexed object to be
modified.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pulls.
For sync, saves 1 ssh connection per remote. For remotedaemon, the same
ssh connection that is already open to run git-annex-shell notifychanges
is reused to pull from the remote.
Only potential problem is that this also enables connection caching
when the assistant syncs with a ssh remote. Including the sync it does
when a network connection has just come up. In that case, cached ssh
connections are likely to be stale, and so using them would hang.
Until I'm sure such problems have been dealt with, this commit needs to
stay on the remotecontrol branch, and not be merged to master.
This commit was sponsored by Alexandre Dupas.
|
| |
|
|
|
|
| |
feed 0.3.9.2.
|
|
|
|
|
|
|
|
|
| |
So far, handling connecting to git-annex-shell notifychanges, and
pulling immediately when a change is pushed to a remote.
A little bit buggy (crashes after the first pull), but it already works!
This commit was sponsored by Mark Sheppard.
|
|
|
|
|
|
|
|
|
|
| |
This will be used by the remote-daemon to quickly tell when changes have
been pushed from some other repository into a ssh remote.
Adjusted the remote-daemon protocol to communicate changed shas, rather
than git branch refs. This way, it can easily check if a sha is new.
This commit was sponsored by Carlos Trijueque Albarran.
|
| |
|
|
|
|
|
|
|
| |
This includes checking when dropping files that any required content
configuration is satisfied. However, it does not yet include an active
check on the required content; the location log is trusted when checking
the required content expression.
|
| |
|
|
|
|
| |
repository, as long as a git-annex branch has been pushed to it, to simplify setup of remote git repositories, including via gitolite.
|
| |
|
|
|
|
|
|
|
| |
Motivation: Hook scripts for nautilus or other file managers
need to provide the user with feedback that a file is being downloaded.
This commit was sponsored by THM Schoemaker.
|
|
|
|
|
|
|
|
|
| |
speedup.
pre-commit hook lock added, so unannex can prevent the hook from running
in a confusing state.
This commit was sponsored by Fredrik Hammar
|
| |
|
|
|
|
|
|
| |
http://git-annex.branchable.com/bugs/Unicode_file_names_ignored_on_Windows/
Not a complete fix yet.
|
|
|
|
|
|
|
|
|
|
| |
"$field-lastchanged" that gives the timestamp of the last change to that field.
Note that this is a nearly entirely free feature. The data was already
stored in the metadata log in an easily accessible way, and already was
parsed to a time when parsing the log. The generation of the metadata
fields may even be done lazily, although probably not entirely (the map
has to be evaulated to when queried).
|
|
|
|
| |
does not exist, or is not a git repo.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is stored in the git-annex branch, but not yet actually hooked up and
used.
|
| |
|
|
|
|
| |
believed to be present on the remote.
|
|
|
|
|
|
|
|
|
| |
unused and unannex
unused: In direct mode, files that are deleted from the work tree are no longer incorrectly detected as unused.
Direct mode `git annex info` slows down a bit due to more stringent
checking, but not by a lot.
|
|
|
|
|
|
| |
rather than crashing non-informatively
Mostly for Windows, which has no sane package management..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regular git file.
This is a new feature, it was not handled before, since it's a bit of an
edge case. However, it can be handled exactly the same as a file/dir
conflict, just leave the non-annexed item alone.
While implementing this, the core resolveMerge' function got a lot simpler
and clearer. Note especially that where before there was an asymetric call to
stagefromdirectmergedir, now graftin is called symmetrically in both cases.
And, in order to add that `graftin us`, the current branch needed to be
known (if there is no current branch, there cannot be a merge conflict).
This led to some cleanups of how autoMergeFrom behaved when there is no
current branch.
This commit was sponsored by Philippe Gauthier.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I think that f5ce1a15d7a35b85ffa938ee950f4749bf445939 didn't quite manage
to actually fix the bug, although I have not checked since its "fix" got
redone.
The test suite now actually checks the file staged in git is a symlink,
rather than relying on the bug casing a later sync failure. This seems a
more reliable way to detect it, and probably avoids a heisenbug in the test
suite.
|
|
|
|
|
|
|
|
|
|
| |
Added test cases for both ways this can happen, with a conflict involving a
file, or a directory.
Cleaned up resolveMerge to not touch the work tree in direct mode, which
turned out to be the only way to handle things.. And makes it much nicer.
Still need to run test suite on windows.
|
| |
|
| |
|
|
|
|
| |
deleted when merging with a remote that added a file by the same name. (Thanks, jkt)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
types of files
Using the extract(1) program to do the heavy lifting.
Decided to make git-annex run pre-commit-annex when committing. Since
git-annex pre-commit also runs it, it'll be run when git commit is run too,
via the pre-commit hook. This basically gives back the pre-commit hook
that git-annex took away. The implementation avoids repeatedly looking
for the hook script when the assistant is running and committing
repeatedly; only checks if the hook is available once.
To make the script simpler, made git-annex metadata -s field?=value
only set a field when it's not already got a value.
This commit was sponsored by bak.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
using !tag and field!=value.
Note that negated globs are not supported. Would have complicated the code
to add them, without changing the data type serialization in a
non-backwards-compatable way.
This commit was sponsored by Denver Gingerich.
|