summaryrefslogtreecommitdiff
path: root/CHANGELOG
Commit message (Collapse)AuthorAge
* version: Added "dependency versions" line.Gravatar Joey Hess2017-04-07
| | | | This commit was sponsored by Anthony DeRobertis on Patreon.
* git annex add -u now supported, analagous to git add -uGravatar Joey Hess2017-04-07
| | | | | | | | | | | | Unlike git add -u, git annex add -u does not update the index for files removed from the working tree. But then, "git add ." stages removals, and "git annex add ." does not, so that's an existing divergence. Seems that --update --batch would need to run git ls-files once per line of batch input, which would surely be too slow, so just throw an error for that. This commit was supported by the NSF-funded DataLad project.
* gcrypt: Support re-enabling to change eg, encryption parameters.Gravatar Joey Hess2017-04-07
| | | | | | | | This was never supported before. And it doesn't re-encrypt the gcrypt repo to the new gcrypt-participants, but it does at least now not crash, and set gcrypt-participants. This commit was sponsored by andrea rota.
* enableremote: Fix re-enabling of existing gcrypt remotes, so that eg, ↵Gravatar Joey Hess2017-04-07
| | | | | | | | | | | | encryption key changes take effect. They were silently ignored, a reversion introduced in 6.20160527. I don't like this regular git remote special case in enableremote, but I can't see a way to get rid of it. So, check if the existing remote is a Remote.Git This commit was sponsored by Trenton Cronholm on Patreon.
* enableremote: When enabling a non-special remote, param=value parameters ↵Gravatar Joey Hess2017-04-07
| | | | | | can't be used, so error out if any are provided. This commit was sponsored by Riku Voipio.
* Disable git-annex's support for GIT_SSH and GIT_SSH_COMMAND, unless ↵Gravatar Joey Hess2017-04-07
| | | | | | | | | | | | | | | | | | | | GIT_ANNEX_USE_GIT_SSH=1 is also set in the environment. This is necessary because as feared, the extra -n parameter that git-annex passes breaks uses of these environment variables that expect exactly the parameters that git passes. For example, see https://github.com/datalad/datalad/issues/1456 It would of course be possible to pre-close stdin before running ssh so not needing the -n, and I think that would not even break ssh's password caching. But it would probably involve a lot of work, possibly would need to deal with some layering violations, and would be error-prone. The really clean fix would be to make all the ssh stuff return a CreateProcess, which could have the handle closed when appropriate, but that would be a large reworing of the code base. This commit was supported by the NSF-funded DataLad project.
* Added remote.<name>.annex-push and remote.<name>.annex-pullGravatar Joey Hess2017-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The former can be useful to make remotes that don't get fully synced with local changes, which comes up in a lot of situations. The latter was mostly added for symmetry, but could be useful (though less likely to be). Implementing `remote.<name>.annex-pull` was a bit tricky, as there's no one place where git-annex pulls/fetches from remotes. I audited all instances of "fetch" and "pull". A few cases were left not checking this config: * Git.Repair can try to pull missing refs from a remote, and if the local repo is corrupted, that seems a reasonable thing to do even though the config would normally prevent it. * Assistant.WebApp.Gpg and Remote.Gcrypt and Remote.Git do fetches as part of the setup process of a remote. The config would probably not be set then, and having the setup fail seems worse than honoring it if it is already set. I have not prevented all the code that does a "merge" from merging branches from remotes with remote.<name>.annex-pull=false. That could perhaps be done, but it would need a way to map from branch name to remote name, and the way refspecs work makes that hard to get really correct. So if the user fetches manually, the git-annex branch will get merged, for example. Anther way of looking at/justifying this is that the setting is called "annex-pull", not "annex-merge". This commit was supported by the NSF-funded DataLad project.
* multicast: New command, uses uftp to multicast annexed files, for eg a ↵Gravatar Joey Hess2017-03-30
| | | | | | classroom setting. This commit was supported by the NSF-funded DataLad project.
* When a http remote does not expose an annex.uuid config, only warn about it ↵Gravatar Joey Hess2017-03-29
| | | | | | once, not every time git-annex is run. Same behavior as for a ssh remote.
* stack.yaml: Update to lts-8.6.Gravatar Joey Hess2017-03-27
|
* releasing package git-annex version 6.201703216.20170321Gravatar Joey Hess2017-03-21
|
* sync --content-of=pathGravatar Joey Hess2017-03-20
| | | | | | | For when you want to sync only some files' contents, not the whole working tree. This commit was sponsored by Anthony DeRobertis on Patreon.
* Support GIT_SSH and GIT_SSH_COMMANDGravatar Joey Hess2017-03-17
| | | | | | | | | | | | | | | | | | | | They are handled close the same as they are by git. However, unlike git, git-annex sometimes needs to pass the -n parameter when using these. So, this has the potential for breaking some setup, and perhaps there ought to be a ANNEX_USE_GIT_SSH=1 needed to use these. But I'd rather avoid that if possible, so let's see if anyone complains. Almost all places where "ssh" was run have been changed to support the env vars. Anything still calling sshOptions does not support them. In particular, rsync special remotes don't. Seems that annex-rsync-transport already gives sufficient control there. (Fixed in passing: Remote.Helper.Ssh.toRepo used to extract remoteAnnexSshOptions and pass them to sshOptions, which was redundant since sshOptions also extracts those.) This commit was sponsored by Jeff Goeke-Smith on Patreon.
* git-annex-shell: run all commands with noMessagesGravatar Joey Hess2017-03-17
| | | | | | | | | | | | | | | | | | | | Fix bug when used with a recently cloned repository, where "merging" messages were included in the output of configlist (and perhaps other commands) and caused a "Failed to get annex.uuid configuration" error. This does not seem to have been a reversion. I saw this with configlist, but it seems possible for other commands to be effected, and it might not always happen only after a fresh clone. Eg, if a foo/git-annex branch is pushed to the remote, the next git-annex-shell will auto-merge it and display the message. Decided to run all git-annex-shell commands with noMessages, even ones that don't currently use stdout for structured communication. Better to keep open the possibility for using stdout in the future. This commit was supported by the NSF-funded DataLad project
* Windows: Fix bug in shell script shebang lookup code that caused a "delayed ↵Gravatar Joey Hess2017-03-13
| | | | | | | | | read on closed handle" error. The bug was that withFile closes the handle afterwards, but the content of the file was not read due to laziness. Using readFile avoids it. This commit was sponsored by Nick Daly on Patreon.
* Drop support for building with old versions of directory, feed, and http-types.Gravatar Joey Hess2017-03-10
|
* Revert "Drop support for building without network-uri."Gravatar Joey Hess2017-03-10
| | | | | | This reverts commit bfad6f5a7d156d5ddf0e5cf3840d8d22f82a2377. Need it in stable w/o backports for the ancient autobuilder.
* Drop support for building with old versions of dns and http-conduit.Gravatar Joey Hess2017-03-10
|
* Drop support for building without network-uri.Gravatar Joey Hess2017-03-10
| | | | | network-uri is available in Debian stable (backports) and testing, so no need to complicate the cabal file anymore
* Windows: Improve handling of shebang in external special remote program, ↵Gravatar Joey Hess2017-03-08
| | | | | | | | | | | | | | | | | | | searching for the program in the PATH. findShellCommand needs a full path to a file in order to check it for a shebang on Windows. It was being run with only the base name of the external special remote program, which would only work when it was in the current directory. This is why users in https://github.com/DanielDent/git-annex-remote-rclone/pull/10 and elsewhere were complaining that the previous improvements to git-annex didn't make git-remote-rclone work on Windows. Also, reworked checkearlytermination, which while it worked, seemed to rely on a race condition. And, improved its error messages. This commit was sponsored by Shane-o on Patreon.
* fsck -q: When a file has bad content, include the name of the file in the ↵Gravatar Joey Hess2017-03-08
| | | | | | warning message. This commit was sponsored by Alexander Thompson on Patreon.
* get -J: Improve distribution of jobs amoung remotes when there are more jobs ↵Gravatar Joey Hess2017-03-08
| | | | | | | | | | | | | | | | than remotes. It was distributing jobs to remotes that were not being used by any other job. But, suppose that there are only 2 remotes, and -J10. In such a case, the first 2 downloads would be distributed amoung the 2 remotes, but the other 8 would all go to remote #1. Improved by keeping a counter of how many jobs are assigned to a remote, and prefer remotes with fewer jobs. Note use of Data.Map.Strict to avoid blowing up space. I kept the bang-patterns as-is, although probably not needed with Data.Map.Strict. This commit was sponsored by Jack Hill on Patreon.
* assistant: Add 1/200th second delay between checking each file in the full ↵Gravatar Joey Hess2017-03-06
| | | | | | | | | | | | | | | | | | transfer scan, to avoid using too much CPU. The slowdown is not going to be large in typical small-ish repos. And it does not seem to matter if the assistant reacts a little bit slower in situations involving the expensive scan, since: a) Those situations typically involve getting back in sync after something has changed on a remote, often after a disconnect of some duration. So taking a few seconds more is not noticable. b) If the scan finds things that it needs to do, it will start blocking anyway after 10 transfers are queued (due to use of queueTransferWhenSmall). So, only the speed of finding the first 10 transfers will be impacted by this change. This commit was sponsored by Jochen Bartl on Patreon.
* Linux standalone builds put the bundled ssh last in PATH, so any system ssh ↵Gravatar Joey Hess2017-03-02
| | | | | | will be preferred over it. This commit was sponsored by Denis Dzyubenko on Patreon.
* status: Propigate nonzero exit code from git status.Gravatar Joey Hess2017-03-02
|
* Bugfix: Passing a command a filename that does not exist sometimes did not ↵Gravatar Joey Hess2017-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | display an error, when a path to a directory was also passed. It was relying on segmentPaths to work correctly, so when it didn't, sometimes the file that did not exist got matched up with a non-null list of results. Fixed by always checking if each parameter exists. There are two reason segmentPaths might not work correctly. For one, it assumes that when the original list of paths has more than 100 paths, it's not worth paying the CPU cost to preserve input orders. And then, it fails when a directory such as "." or ".." or /path/to/repo is in the input list, and the list of found paths does not start with that same thing. It should probably not be using dirContains, but something else. But, it's not clear how to handle this fully. Consider when [".", "subdir"] has been expanded by git ls-files to ["subdir/1", "subdir/2"] -- Both of the inputs contained those results, so there's no one right answer for segmentPaths. All these would be equally valid: [["subdir/1", "subdir/2"], []] [[], ["subdir/1", "subdir/2"]] [["subdir/1"], [""subdir/2"]] So I've not tried to improve segmentPaths.
* releasing package git-annex version 6.20170301.16.20170301.1Gravatar Joey Hess2017-03-01
|
* Fix reversion in yesterday's release that made SHA1E and MD5E backends not work.Gravatar Joey Hess2017-03-01
|
* 6.20170301 version for hackage6.20170301Gravatar Joey Hess2017-03-01
| | | | No changes from 6.20170228; a new version number was needed due to a problem with Hackage.
* releasing package git-annex version 6.201702286.20170228Gravatar Joey Hess2017-02-28
|
* release prepGravatar Joey Hess2017-02-28
|
* inheritable annex.securehashesonlyGravatar Joey Hess2017-02-27
| | | | | | | | | | | | | | | * init: When annex.securehashesonly has been set with git-annex config, copy that value to the annex.securehashesonly git config. * config --set: As well as setting value in git-annex branch, set local gitconfig. This is needed especially for annex.securehashesonly, which is read only from local gitconfig and not the git-annex branch. doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn has the rationalle for doing it this way. There's no perfect solution; this seems to be the least-bad one. This commit was supported by the NSF-funded DataLad project.
* reorgGravatar Joey Hess2017-02-27
|
* securehash matchingGravatar Joey Hess2017-02-27
| | | | | | | Added --securehash option to match files using a secure hash function, and corresponding securehash preferred content expression. This commit was sponsored by Ethan Aubin.
* make fsck check annex.securehashesonly, and new tip for working around SHA1 ↵Gravatar Joey Hess2017-02-27
| | | | | | collisions with git-annex This commit was sponsored by andrea rota.
* annex.securehashesonlyGravatar Joey Hess2017-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cryptographically secure hashes can be forced to be used in a repository, by setting annex.securehashesonly. This does not prevent the git repository from containing files with insecure hashes, but it does prevent the content of such files from being pulled into .git/annex/objects from another repository. We want to make sure that at no point does git-annex accept content into .git/annex/objects that is hashed with an insecure key. Here's how it was done: * .git/annex/objects/xx/yy/KEY/ is kept frozen, so nothing can be written to it normally * So every place that writes content must call, thawContent or modifyContent. We can audit for these, and be sure we've considered all cases. * The main functions are moveAnnex, and linkToAnnex; these were made to check annex.securehashesonly, and are the main security boundary for annex.securehashesonly. * Most other calls to modifyContent deal with other files in the KEY directory (inode cache etc). The other ones that mess with the content are: - Annex.Direct.toDirectGen, in which content already in the annex directory is moved to the direct mode file, so not relevant. - fix and lock, which don't add new content - Command.ReKey.linkKey, which manually unlocks it to make a copy. * All other calls to thawContent appear safe. Made moveAnnex return a Bool, so checked all callsites and made them deal with a failure in appropriate ways. linkToAnnex simply returns LinkAnnexFailed; all callsites already deal with it failing in appropriate ways. This commit was sponsored by Riku Voipio.
* Removed support for building with the old cryptohash library.Gravatar Joey Hess2017-02-24
| | | | | Building with that library made git-annex not support SHA3; it's time for that to always be supported in case SHA2 dominoes.
* SHA1 collisions in key names was more exploitable than I thoughtGravatar Joey Hess2017-02-24
| | | | | | | | | | | | Yesterday's SHA1 collision attack could be used to generate eg: SHA256-sfoo--whatever.good SHA256-sfoo--whatever.bad Such that they collide. A repository with the good one could have the bad one swapped in and signed commits would still verify. I've already mitigated this.
* updateGravatar Joey Hess2017-02-24
|
* make file2key reject E* backend keys with a long extensionGravatar Joey Hess2017-02-24
| | | | | | | | | | | | | | | | | | | | I am not happy that I had to put backend-specific code in file2key. But it would be very difficult to avoid this layering violation. Most of the time, when parsing a Key from a symlink target, git-annex never looks up its Backend at all, so adding this check to a method of the Backend object would not work. The Key could be made to contain the appropriate Backend, but since Backend is parameterized on an "a" that is fixed to the Annex monad later, that would need Key to change to "Key a". The only way to clean this up that I can see would be to have the Key contain a LowlevelBackend, and put the validation in LowlevelBackend. Perhaps later, but that would be an extensive change, so let's not do it in this commit which may want to cherry-pick to backports. This commit was sponsored by Ethan Aubin.
* typoGravatar Joey Hess2017-02-24
|
* Tighten key parser to not accept keys containing a non-numeric fields, which ↵Gravatar Joey Hess2017-02-24
| | | | | | | | | could be used to embed data useful for a SHA1 attack against git. Also todo about why this is important, and with some further hardening to add. This commit was sponsored by Ignacio on Patreon.
* status: Pass --ignore-submodules=when option on to git status.Gravatar Joey Hess2017-02-20
| | | | | | | Didn't make --ignore-submodules without a value be handled because I can't see a way to make optparse-applicative parse that. I've opened a bug requesting a way to do that: https://github.com/pcapriotti/optparse-applicative/issues/243
* make curl show http errors to stderrGravatar Joey Hess2017-02-20
| | | | | | | | | | | | | * Run curl with -S, so HTTP errors are displayed, even when it's otherwise silent. * When downloading in --json or --quiet mode, use curl in preference to wget, since curl is able to display only errors to stderr, unlike wget. This does mean that downloadQuiet is only silent on stdout, not necessarily on stderr, which affects a couple other calls of it. For example, downloading the .git/config of a http remote may show an error message now, perhaps with slightly suboptimal formatting due to other output.
* Run wget with -nv instead of -q, so it will display HTTP errors.Gravatar Joey Hess2017-02-20
| | | | | | This adds one extra line of output when a download is successful, after the progress bar. I don't much like that, but wget does not provide a way to show HTTP errors without it.
* adjust: Fix behavior when used in a repository that contains submodules.Gravatar Joey Hess2017-02-20
| | | | | Also fixed the LsFiles parser to not assume its output has a fixed width type field.
* git-annex.cabal: Make crypto-api a dependency even when built w/o webapp and ↵Gravatar Joey Hess2017-02-20
| | | | | | | | test suite. The p2p code made it always be needed. This commit was sponsored by Anthony DeRobertis on Patreon.
* sync hack to make updateInstead work on eg FATGravatar Joey Hess2017-02-17
| | | | | | | | | | | | sync: When syncing with a local repository located on a crippled filesystem, run the post-receive hook there, since it wouldn't get run otherwise. This makes pushing to repos on FAT-formatted removable drives update them when receive.denyCurrentBranch=updateInstead. Made Remote.Git export onLocal, which was cleaned up to not have so many caveats about its use. This commit was sponsored by Jeff Goeke-Smith on Patreon.
* post-recive hook to make updateInstead work in direct mode and adjusted branchesGravatar Joey Hess2017-02-17
| | | | | | | | * Added post-recieve hook, which makes updateInstead work with direct mode and adjusted branches. * init: Set up the post-receive hook. This commit was sponsored by Fernando Jimenez on Patreon.
* make query commands not output extraneous messagesGravatar Joey Hess2017-02-16
| | | | | | config group groupwanted numcopies schedule wanted required: Avoid displaying extraneous messages about repository auto-init, git-annex branch merging, etc, when being used to get information.