| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
It's a code smell, can lead to hard to diagnose error messages.
|
| | |
|
| |
|
|
| |
Also refactored some code to reduce duplication.
|
| |
|
|
| |
annex.diskreserve limit.
|
| |
|
|
| |
repo does not have a copy of the content, preserve the bad content in .git/annex/bad/ to avoid further data loss.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
specified directory.
This is a nearly free feature; it piggybacks on the location log lookups
done for the numcopies stats. So, the only extra overhead is updating
the map of repository sizes.
However, I had to switch to Data.Map.Strict, which needs containers 0.5.
If backporting to wheezy, will probably need to revert this commit.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This bug used to only afflict file:/// urls, but became more exposed
by b1483ee577dded9e00f8d82d52a806ee02888b2c.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
added, the file will be checked into git rather than being added to the annex. Previously, git annex add skipped over such files; this new behavior is more useful in direct mode.
|
| |
|
|
| |
respectively, to contain whitespace.
|
| | |
|
| | |
|
| |
|
|
| |
This is much more space efficient!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
corresponding to duplicated files they process.
|
| |
|
|
| |
their contents, don't override the user's provided filename with filenames that the special remote suggests. Also, don't allow adding the url if the special remote says it contains multiple files.
|
| |
|
|
|
|
|
| |
been downloaded before, even when the url has changed.
To support this, always store itemid in metadata; before this was only done
when annex.genmetadata was set.
|
| |
|
|
| |
Not a behavior change unless you were passing it to a command that ignored it.
|
| | |
|
| |
|
|
| |
"git annex help <command>"
|
| |
|
|
|
|
|
|
| |
Common command man pages all split out and often expanded.
A few sections split out into their own pages.
Still need to do all the other commands..
|
| |
|
|
| |
backend. Useful in rare cases.
|
| |
|
|
| |
be present on a remote.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
bittorrent etc urls.
|
| |
|
|
|
|
|
|
| |
Seen for example, a newly checked out git submodule. In this case,
.git/HEAD is a raw sha, rather than the usual reference to a ref.
Removed currentSha in passing, since it was a more roundabout way of
doing what headSha does, and headSha is more robust.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
~/.config/git-annex/program, when possible.
Most of the time, there will be no discreprancy between programPath and
readProgramFile.
But, the programFile might have been written by an old version of git-annex
that is still installed, while a newer one is currently running. In this
case, we want to run the same one that's currently running.
This is especially important for things like the GIT_SSH=git-annex used for
ssh connection caching.
The only code that still uses readProgramFile directly is the upgrade code,
which needs to know where the standalone git-annex was installed, in order to
upgrade it.
|
| |
|
|
|
|
|
|
|
|
|
| |
push, as long as the remote branch is an ancestor of the local branch, to better support bare git repos.
See my comment in the bug report for analysis; basically this is safe
because it's a non-forced push, so won't lose history. Even if it was a
forced push or somehow races, things will eventually become consistent and
no git-annex branch info will be lost.
(This used to be done, but it forgot to do it since version 4.20130909.)
|
| |
|
|
|
|
| |
In this case there must be staged changes in the index (if there is
anything to unannex), and the unannex code path needs to run with a clean
index.
|
| |
|
|
| |
in progress at the same time in the same repo without it getting confused about which files have been checked for which remotes.
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out sqlite does not like having its database deleted out from
underneath it. It might suffice to empty the table, but I would rather
start each fsck over with a new database, so I added a lock file, and
running incremental fscks use a shared lock.
This leaves one concurrency bug left; running two concurrent fsck --more
will lead to: "SQLite3 returned ErrorBusy while attempting to perform step."
and one or both will fail. This is a concurrent writers problem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Database.Handle can now be given a CommitPolicy, making it easy to specify
transaction granularity.
Benchmarking the old git-annex incremental fsck that flips sticky bits
to the new that uses sqlite, running in a repo with 37000 annexed files,
both from cold cache:
old: 6m6.906s
new: 6m26.913s
This commit was sponsored by TasLUG.
|
| |
|
|
|
|
| |
This makes interrupt and resume work, robustly.
But, incremental fsck is slowed down by all those transactions..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Did not keep backwards compat for sticky bit records. An incremental fsck
that is already in progress will start over on upgrade to this version.
This is not yet ready for merging. The autobuilders need to have sqlite
installed.
Also, interrupting a fsck --incremental does not commit the database.
So, resuming with fsck --more restarts from beginning.
Memory: Constant during a fsck of tens of thousands of files.
(But, it does seem to buffer whole transation in memory, so
may really scale with number of files.)
CPU: ?
|
| |
|
|
|
|
|
|
|
| |
* sync: Use the ssh-options git config when doing git pull and push.
* remotedaemon: Use the ssh-options git config.
Note that the rename env var means that if a new git-annex calls an old one
for git-annex ssh, or a new calls an old, nothing much will go wrong;
just ssh caching won't happen.
|
| | |
|
Joey Hess
Jean Jordaan