| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
from logged url info before checking for the specified prefix.
This doesn't change what GETURLS returns, but only whether it matches
any prefix that the external special remote asked for.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
wildcard is passed to a git-annex command like add or find.
Note that previously, `git annex find *.jpg` would find eg, foo/bar.jpg.
That was never intended or documented behavior, so I'm going to change it.
But this is potentially a behavior change if someone discovered that
behavior and relied on it despite it being accidental. Oh well.. can't make
an omlette w/o breaking some eggs.
|
| |
|
|
| |
for "git annex sync" as well as "git-annex sync".
|
| | |
|
| |
|
|
|
|
|
|
|
| |
git-annex was installed from the standalone tarball.
This was introduced by commit 849a4b1a0d71071a602f552125fd7e25689662db
However, the same problem could affect other calls to programPath,
specifically some on the assistant. So, I fixed it at a deeper level.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this situation, curl -o exits successfully without creating the output
file.
There was already a workaround for curl file:/// but I did not realize this
also affected regular url downloads.
To fix it, pre-create the destination file before starting curl.
Since we cannot always know the size of an url before trying to download
it, let's always do this.
Note that since curl is told -C -, we have to consider if this
makes curl try to do a ranged download, which might fail on some servers
where a regular download would have succeeded. My testing indicates
this isn't a problem; since the file is empty, curl seems to not try to
do a ranged download.
Original report: https://github.com/datalad/datalad/issues/79
Curl bug report: https://github.com/bagder/curl/issues/183
|
| |
|
|
| |
command-line length limits and cause the commit to fail. This only happened when using the assistant in an indirect mode repository.
|
| |
|
|
| |
git-annex branch.
|
| |
|
|
| |
Not a behavior change unless you were passing it to a command that ignored it.
|
| |
|
|
| |
"git annex help <command>"
|
| |
|
|
| |
backend. Useful in rare cases.
|
Joey Hess