| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
Needed for FSEvents, which calls that hook for modified files.
inotify seems to call the add hook, so I didn't notice it before.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a file is changed in direct mode, the old content is probably lost
(at least from the local repo), and bookeeping needs to be updated to
reflect this.
Also, synthetic add events are generated at assistant startup, so
make it detect when the file has not really changed, and avoid re-adding
it.
This does add the overhead of querying the runing git cat-file for the
key that's recorded in git for the file, each time a file is added or
modified in direct mode.
|
| |
|
|
| |
To handle direct mode merging.
|
| |
|
|
|
| |
Works with inotify, but I think in kqueue we don't get events
existing files that get modified.
|
| |
|
|
|
|
|
|
|
|
| |
git add --update cannot be used, because it'll stage typechanged direct
mode files. Intead, use ls-files to find deleted files, and stage them
ourselves.
It seems that no commit was made before when the scan staged deleted files.
(Probably masked since if files were added, a commit happened then..)
Now that I'm doing the staging, I was also able to fix that bug.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This allows it to use Build.SysConfig to always install the programs
configure detected. Amoung other fixes, this ensures the right uuid
generator and checksum programs are installed.
I also cleaned up the handling of lsof's path; configure now checks for
it in PATH, but falls back to looking for it in sbin directories.
|
| | |
|
| |
|
|
|
| |
This got broken when I optimised reconnecting with remotes, to not do a
full scan if the remote was not diverged.
|
| | |
|
| |
|
|
|
|
|
| |
* get/copy --auto: Transfer data even if it would exceed numcopies,
when preferred content settings want it.
* drop --auto: Fix dropping content when there are no preferred content
settings.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
See http://git-annex.branchable.com/forum/dot_git_slash_annex_slash_tmp/
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
It was doubly broken; both missing a slash, and containing
"runshell git-annex", while some parts of the code expected it to be a
simple path to a program. This appears to include the transfer queue
runner, and the code that starts a new assistant process when switching to
another repository in the webapp.
|
| | |
|
| |
|
|
|
|
| |
variables before running the system web browser.
Should fix a crash reported on OSX.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
I'd forgotten this existed!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Partition syncRemotes into ones needing git sync (ie, non-special remotes),
and ones needing data sync (ie, non-XMPP remotes).
|
| |
|
|
|
|
| |
Noticed that when pairing, sometimes both sides start to push, and the other
side sends a PushRequest, and the two deadlock, neither doing anything.
(Timeout eventually breaks this.) So, let both run at the same time.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This should help prevent git-annex clients receiving messages that
were intended for normal clients they're sharing the account with.
Changed XMPP protocol use to always send chat messages directed at the
specific client, as the negative priority blocks less directed messages.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
I decided to use the fallback push mode from the beginning for XMPP, since
while it uses some ugly branches, it avoids the possibility of a normal
push failing, and needing to pull and re-push. Due to the overhead of XMPP,
and the difficulty of building such a chain of actions due to the async
implementation, this seemed reasonable.
It seems to work great!
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This improves type safety.
|
| | |
|
Joey Hess