| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
To debug a bug report, but generally useful.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The setDifferences that got added to initialize turns out to make a git
commit, and before ensureCommit has been used. Thus, repo init can fail
when the system has a broken hostname etc.
Move the ensureCommit to the very first thing to avoid this kind of breakage.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
special remote. This was a reversion caused by the relative path changes in 5.20150113.
The directory special remote was not affected in its normal configuration,
since annex-directory is an absolute path normally. But it could fail
when a relative path was used.
The git remote was affected even when an absolute path to it was used in
.git/config, since git-annex now converts all such paths to relative.
|
| |
|
|
|
|
|
| |
getting content if the disk is too full.
We can't check if there's enough disk space to download the content,
but we *can* check if there's certainly not enough!
|
| |
|
|
|
|
| |
Since we started using this for git repos, when a remote was on another
drive, it resulted in a bogus relative path to it being used by git-annex,
which didn't work.
|
| | |
|
| |
|
|
| |
where the menu file is treated as a git-annex program.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Otherwise, if there's a file in the repo with a name matching the ref,
git could get confused and the merge not work.
|
| |
|
|
|
| |
I had some cargo culting in there that used the wrong type, so it failed
to parse old logs, and overwrote them with the new log.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
webapp: When adding another local repository, and combining it with the
current repository, the new repository's remote path was set to "." rather
than the path to the current repository. This was a reversion caused by the
relative path changes in 5.20150113.
|
| |
|
|
|
|
|
|
|
|
|
| |
in version 5.20150406.
git-checkignore refuses to work if any pathspec options are set. Urgh.
I audited the rest of git, and no other commands used by git-annex have
such limitations. Indeed, AFAICS, *all* other commands support
--literal-pathspecs. So, worked around this where git-checkignore is
called.
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't quite understand the cause of the deadlock. It only occurred
when git-annex-shell transferinfo was being spawned over ssh to feed
download transfer progress back. And if I removed this line from
feedprogressback, the deadlock didn't occur:
bytes <- readSV v
The problem was not a leaked FD, as far as I could see. So what was it?
I don't know.
Anyway, this is a nice clean implementation, that avoids the deadlock.
Just fork off the async threads to handle filtering the stdout and stderr,
and let them clean up their handles whenever they decide to exit.
I've verified that the handles do get promptly closed, although a little
later than I would expect. Presumably that "little later" is what
was making waiting on the threads deadlock.
Despite the late exit, the last line of stdout and stderr appears where
I'd want it to, so I guess this is ok..
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
commands to hang at the end of a file transfer.
Stderr reader blocks waiting for all stderr, and so blocks the process ever
exiting.
I tried several ways to get around this, but no success yet. For now,
disable the stderr reader entirely.
|
| |
|
|
| |
Windows is still building with an older git.
|
| | |
|
| |
|
|
| |
This is much more space efficient!
|
| |\ |
|
| | | |
|
| |/
|
|
|
|
|
|
| |
well enough for sshcaching.
ssh tries to hard link a fifo, and if not, complains:
muxserver_listen: link mux listener .git/annex/ssh/SHARD1@iabak.archiveteam.org.QK8zOCbtNebI7q54 => .git/annex/ssh/SHARD1@iabak.archiveteam.org: Operation not permitted
|
| | |
|
| |
|
|
|
|
|
|
| |
single git-annex command. (try 2)
New approach is to do it the expensive way for the first 100 paths
on the command line, but then assume the user doesn't care about order too
much and fall back to the cheap way that does not preserve order.
|
| |
|
|
|
|
|
|
|
| |
passed to a single git-annex command."
This reverts commit 5492d8f4ddbd398e0188da9daed840908d1198c0.
Whoops, git ls-files does not always output in the input ordering.
That's why all this work is needed. Urk.
|
| |
|
|
|
|
|
|
| |
This will only ever result in a few more git-ls-files being run than were run
before. (Only 1 more is really needed, but around 10 more are currently run
for a max length command line.)
So, no need to worry about the extra zombie, or lost laziness due to concat.
|
| |
|
|
| |
single git-annex command.
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
| |
Seems list order matters, I don't know why, but have reported it on #tasty
|
| |
|
|
|
|
|
| |
1:2.0.
Git.Merge needs >= 1.7.7.6 if built with such a version; rest of code all
probes git version at runtime.
|
| |
|
|
|
| |
This is confusing because I updated the affected tarballs using the version
number of the last release.
|
| |
|
|
|
|
|
| |
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.
|
Joey Hess