| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
| |
I've eyeballed all --json commands, and the only difference should be
that some fields are re-ordered.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
metadata --json output format has changed, adding a inner json object
named "fields" which contains only the fields and their values.
This should be easier to parse than the old format, which mixed up
metadata fields with other keys in the json object.
Any consumers of the old format will need to be updated.
This adds a dependency on unordered-containers for parsing MetaData
from JSON, but it's a free dependency; aeson pulls in that library.
|
| |
|
|
| |
using make, not cabal. This speeds up git-annex statup time by around 50%.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tarball on hackage will include only the files needed for cabal install;
it is NOT the full git-annex source tree. While it's totally obnoxious that
cabal files need every file listed out when basic wildcard support could
avoid hundreds of lines, and have to be maintained when files are added,
this does get the tarball size back down to 1 mb.
This also stops stack from complaining that it found modules not listed in
the cabal file.
debian/changelog, debian/NEWS, debian/copyright: Converted to symlinks
to CHANGELOG, NEWS, and COPYRIGHT, which used to symlink to these instead.
This avoids needing to include debian/ in the hackage tarball.
Setup.hs: Build man pages at install time using make and mdwn2man.
If it fails, which it probably will on windows, just skip installing
them.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
were not before.
Removed the instance LensGpgEncParams RemoteConfig because it encouraged
code that does not take the RemoteGitConfig into account.
RemoteType's setup was changed to take a RemoteGitConfig,
although the only place that is able to provide a non-empty one is
enableremote, when it's changing an existing remote. This led to several
folow-on changes, and got RemoteGitConfig plumbed through.
|
| | |
|
| | |
|
| |
|
|
| |
This is probably a git bug that stuck in its interface.
|
| |
|
|
| |
dotfile in its root.
|
| |
|
|
|
|
|
|
| |
subdirectory of the repository.
This affected git annex view. It turns out that some other places
that use GIT_INDEX_FILE were already working around the bug. I removed the
workaround from Annex.Branch since the new workaround will do.
|
| |
|
|
| |
nonstandard place.
|
| |
|
|
|
|
| |
added to git as-is.
(git add of a pointer file already did the right thing)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
sometimes not replace pointer files.
The keys database handle needs to be closed after merging, because the
smudge filter, in another process, updates the database. Old cached info
can be read for a while from the open database handle; closing it ensures
that the info written by the smudge filter is available.
This is pretty horribly ad-hoc, and it's especially nasty that the
transferrer closes the database every time.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it might contain changes that have not yet been propigated to the original branch.
Could not think of a foolproof way to detect if the old adjusted branch was
just behind the current branch. It's possible that the user amended the
adjusting commit at the head of the adjusted branch, for example.
I decided to bail in this situation, instead of just entering the old
branch, so that if git annex adjust succeeds the user is always in a
*current* adjusted branch, not some old and out of date one.
What could perhaps be done is enter the old branch and then update it. But
that seems too magical; the user may have rebased master or something or
may not want to propigate the changes from the old branch. Best to error
out.
|
| | |
|
| |
|
|
| |
what's used in initremote.
|
| | |
|
| |
|
|
|
|
| |
This is useful for makking a special remote that anyone with a clone of the
repo and your public keys can upload files to, but only you can decrypt the
files stored in it.
|
| |
|
|
|
|
|
| |
core.symlinks=true, store object contents in mixed case hash directories so that symlinks will point to them.
Contents are searched for in both locations, same as before, so this
does not add any overhead.
|
| |
|
|
| |
something so that reinject --known will work.
|
| |
|
|
|
|
|
|
|
|
|
| |
remote.<name>.annex-gnupg-decrypt-options, which are passed to gpg when it's decrypting data.
The naming is unofrtunately not consistent, but the gnupg-options
were only used for encrypting, and it's too late to change that.
It would be nice to have a third setting that is always passed to gnupg,
but ~/.gnupg/options can be used to specify such global options when really
needed.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Since git-annex unsets these when started, they have to be explicitly
propigated. Also, this makes --git-dir and --work-tree settings be
reflected in the environment.
The need for this came up in
https://github.com/DanielDent/git-annex-remote-rclone/issues/3
|
| | |
|
| |
|
|
| |
cygwin
|
| |
|
|
|
|
| |
* map: Hide dead repositories that are not connected to the graph.
* map: Changed colors; red is used for untrusted repositories and grey
for dead.
|
| |
|
|
| |
back to the master branch.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
probe. Do not mark it as annex-ignore, so it will be tried again later.
|
| |
|
|
| |
its input, which resulted in git add bypassing git-annex.
|
| |
|
|
|
| |
AFAICS, it's not only affecting resumes, but any upload to a special remote
with chunking enabled.
|
| |
|
|
|
|
| |
It started exporting a isSymbolicLink which supports windows. But,
git-annex does no use symlinks on windows yet and this conflicts with the
function by the same name from unix-compat, so hide it.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also, I had the logic backwards in the version comparison.
|
| | |
|
| |
|
|
|
|
| |
used chunking. This bug could also expose the names of keys to such remotes.
This is a low-severity security hole.
|
| |
|
|
|
|
|
|
| |
I'd prefer to use the env var, but let's use what git currently supports.
Revert this when the env var gets supported.
Note that the version checking assumes git 2.8.2 will get support for the
switch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
default
git 2.8.1 (or perhaps 2.9.0) is going to prevent git merge from merging in
unrelated branches. Since the webapp's pairing etc features often combine
together repositories with unrelated histories, work around this behavior
change by setting GIT_MERGE_ALLOW_UNRELATED_HISTORIES when the assistant
merges.
Note though that this is not done for git annex sync's merges, so
it will follow git's default or configured behavior.
|
| |
|
|
|
|
| |
When git-annex is used with a git version older than 2.2.0, disable support for
adjusted branches, since GIT_COMMON_DIR is needed to update them and was first
added in that version of git.
|
| | |
|
| |
|
|
| |
effect when on a crippled filesystem. Thanks, divergentdave.
|
| |
|
|
| |
refer to a file
|
Yaroslav Halchenko
Joey Hess