summaryrefslogtreecommitdiff
path: root/debian/changelog
Commit message (Collapse)AuthorAge
* map: Support remotes with /~/ and /~user/Gravatar Joey Hess2011-11-11
| | | | | | | | | | More accurately, it was supported already when map uses git-annex-shell, but not when it does not. Note that the user name cannot be shell escaped using git-annex's current approach for shell escaping. I tried and some shells like dash cannot cd ~'joey'. Rest of directory is still shell escaped, not for security but in case a directory has a space or other weird character.
* Automatically fix up badly formatted uuid.log entries produced by ↵Gravatar Joey Hess2011-11-11
| | | | 3.20111105, whenever the uuid.log is changed (ie, by init or describe).
* Optimized copy --from and get --from to avoid checking the location log for ↵Gravatar Joey Hess2011-11-10
| | | | | | | files that are already present. This can be a significant speedup when running in large trees that are only missing a few files; it makes copy --from just as fast as get.
* content lockingGravatar Joey Hess2011-11-09
| | | | | I've tested that this solves the cyclic drop problem. Have not looked at cyclic move, etc.
* Handle a case where an annexed file is moved into a gitignored directory, by ↵Gravatar Joey Hess2011-11-07
| | | | having fix --force add its change.
* releasing version 3.201111073.20111107Gravatar Joey Hess2011-11-07
|
* Bugfix: In the past two releases, git-annex init has written the uuid.log in ↵Gravatar Joey Hess2011-11-07
| | | | | | | | | | | | | the wrong format, with the UUID and description flipped. This is my own damn fault for not making UUID a real type, and then relying on the type checker to ensure my refactoring was correct -- which it wasn't! I should probably add code to clean up bogus entries in the uuid.log, but right now I want to get the fix out there to prevent people experiencing this bug. I should also make UUID a real data type.
* Don't try to read config from repos with annex-ignore set.Gravatar Joey Hess2011-11-07
|
* merge: Use fast-forward merges when possible.Gravatar Joey Hess2011-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thanks Valentin Haenel for a test case showing how non-fast-forward merges could result in an ongoing pull/merge/push cycle. While the git-annex branch is fast-forwarded, git-annex's index file is still updated using the union merge strategy as before. There's no other way to update the index that would be any faster. It is possible that a union merge and a fast-forward result in different file contents: Files should have the same lines, but a union merge may change their order. If this happens, the next commit made to the git-annex branch will have some unnecessary changes to line orders, but the consistency of data should be preserved. Note that when the journal contains changes, a fast-forward is never attempted, which is fine, because committing those changes would be vanishingly unlikely to leave the git-annex branch at a commit that already exists in one of the remotes. The real difficulty is handling the case where multiple remotes have all changed. git-annex does find the best (ie, newest) one and fast forwards to it. If the remotes are diverged, no fast-forward is done at all. It would be possible to pick one, fast forward to it, and make a merge commit to the rest, I see no benefit to adding that complexity. Determining the best of N changed remotes requires N*2+1 calls to git-log, but these are fast git-log calls, and N is typically small. Also, typically some or all of the remote refs will be the same, and git-log is not called to compare those. In the real world I expect this will almost always add only 1 git-log call to the merge process. (Which already makes N anyway.)
* releasing version 3.201111053.20111105Gravatar Joey Hess2011-11-05
|
* Pass -t to rsync to preserve timestamps.Gravatar Joey Hess2011-11-04
|
* use SHA256 by defaultGravatar Joey Hess2011-11-04
| | | | | | | | | | | | | | | | | | | | | | | | To get old behavior, add a .gitattributes containing: * annex.backend=WORM I feel that SHA256 is a better default for most people, as long as their systems are fast enough that checksumming their files isn't a problem. git-annex should default to preserving the integrity of data as well as git does. Checksum backends also work better with editing files via unlock/lock. I considered just using SHA1, but since that hash is believed to be somewhat near to being broken, and git-annex deals with large files which would be a perfect exploit medium, I decided to go to a SHA-2 hash. SHA512 is annoyingly long when displayed, and git-annex displays it in a few places (and notably it is shown in ls -l), so I picked the shorter hash. Considered SHA224 as it's even shorter, but feel it's a bit weird. I expect git-annex will use SHA-3 at some point in the future, but probably not soon! Note that systems without a sha256sum (or sha256) program will fall back to defaulting to SHA1.
* add changelog for bugfixGravatar Joey Hess2011-11-04
|
* Record uuid when auto-initializing a remote so it shows in status.Gravatar Joey Hess2011-11-02
|
* fixed my build environmentGravatar Joey Hess2011-10-31
|
* better command nameGravatar Joey Hess2011-10-31
|
* The fromkey command now takes the key as its first parameter. The --key ↵Gravatar Joey Hess2011-10-31
| | | | option is no longer used.
* Removed the setkey command, and added a setcontent command with a more ↵Gravatar Joey Hess2011-10-31
| | | | useful interface.
* unused, dropunused: Now work in bare repositories.Gravatar Joey Hess2011-10-29
| | | | | Turned out I had already done all the work needed to support this when unused started checking all branches.
* fsck: Now works in bare repositories.Gravatar Joey Hess2011-10-29
| | | | | | | | | Checks location log information, and file contents. Does not check that numcopies is satisfied, as .gitattributes information about numcopies is not available in a bare repository. In practice, that should not be a problem, since fsck is also run in a checkout and will check numcopies there.
* status: Now always shows the current repository, even when it does not ↵Gravatar Joey Hess2011-10-28
| | | | appear in uuid.log.
* drop --from is now supported to remove file content from a remote.Gravatar Joey Hess2011-10-28
|
* Fail if --from or --to is passed to commands that do not support them.Gravatar Joey Hess2011-10-27
|
* uninit: Add guard against being run with the git-annex branch checked out.Gravatar Joey Hess2011-10-27
|
* wordingGravatar Joey Hess2011-10-27
|
* reap in onLocalGravatar Joey Hess2011-10-27
| | | | Each onLocal call involves a new Annex state, so needs to clean up after it.
* Sped up some operations on remotes that are on the same host.Gravatar Joey Hess2011-10-27
| | | | | | | | | | | | | | Specifically, disabled trying to update the git-annex branch on the remote, since that data is never used by operations that act on such remotes. Also, when copying content to such a remote, skip committing the presence information changes to its git-annex branch. Leaving it in the journal there is ok: Any command run on the remote that needs the info will flush the journal. This may partially solve this bug: http://git-annex.branchable.com/bugs/fails_to_handle_lot_of_files/ Although I still see unreaped git processes piling up when doing a copy --to.
* releasing version 3.201110253.20111025Gravatar Joey Hess2011-10-25
|
* updateGravatar Joey Hess2011-10-25
|
* git-annex-shell: GIT_ANNEX_SHELL_READONLY and GIT_ANNEX_SHELL_LIMITED ↵Gravatar Joey Hess2011-10-15
| | | | | | environment variables can be set to limit what commands can be run. This could be used by eg, gitolite.
* migrate: Copy url logs for keys when migrating.Gravatar Joey Hess2011-10-15
|
* A remote can have a annexUrl configured, that is used by git-annex instead ↵Gravatar Joey Hess2011-10-14
| | | | of its usual url. (Similar to pushUrl.)
* prep releaseGravatar Joey Hess2011-10-11
|
* oopsGravatar Joey Hess2011-10-11
|
* fix git 1.7.7 breakageGravatar Joey Hess2011-10-11
| | | | | | | | | | | | | | | | * This version of git-annex only works with git 1.7.7 and newer. The breakage with old versions is subtle, and affects annex.numcopies .gitattributes settings, so be sure to upgrade git to 1.7.7. (Debian package now depends on that version.) * Don't pass absolute paths to git show-attr, as it started following symlinks when that's done in 1.7.7. Instead, use relative paths, which show-attr only handles 100% correctly in 1.7.7. Closes: #645046 Unfortunatly I can find no way to work with the old and new gits, as the old had bugs that require absolute paths, while the new doesn't like them at all. And the behavior of git show-attr in 1.7.7. is the same as eg, git add of an absolute path to a symlink, so seems entirely intentional and not likely to change.
* reorderGravatar Joey Hess2011-10-10
|
* Now supports git's insteadOf configuration, to modify the url used to access ↵Gravatar Joey Hess2011-10-09
| | | | a remote. Note that pushInsteadOf is not used; that and pushurl are reserved for actual git pushes. Closes: #644278
* git-annex-shell uuid verificationGravatar Joey Hess2011-10-06
| | | | | | | | | | | * git-annex now asks git-annex-shell to verify that it's operating in the expected repository. * Note that this git-annex will not interoperate with remotes using older versions of git-annex-shell. The reason for this check is to avoid git-annex getting confused about what remote repository actually contains a value. It's a prerequisite for supporting git insteadOf aliases.
* add timestamps to remote.logGravatar Joey Hess2011-10-06
|
* Add timestamps to trust.log.Gravatar Joey Hess2011-10-06
|
* add timestamp to uuid.logGravatar Joey Hess2011-10-06
| | | | | | | | * New or changed repository descriptions in uuid.log now have a timestamp, which is used to ensure the newest description is used when the uuid.log has been merged. * Note that older versions of git-annex will display the timestamp as part of the repository description, which is ugly but otherwise harmless.
* Add locking to avoid races when changing the git-annex branch.Gravatar Joey Hess2011-10-03
|
* Contain the zombie hordes.aGravatar Joey Hess2011-10-02
| | | | | Specifically, when using gpg, a zombie is forked for each file, so waiting until shutdown to reap won't do.
* When displaying a list of repositories, show git remote names in addition to ↵Gravatar Joey Hess2011-09-30
| | | | their descriptions.
* status: List all known repositories.Gravatar Joey Hess2011-09-30
|
* Fix referring to remotes by uuid.Gravatar Joey Hess2011-09-30
| | | | I think that I broke this in some fairly recent refactoring.
* convert all git read/write functions to use ByteStringsGravatar Joey Hess2011-09-29
| | | | | | | | | | This yields a second or so speedup in unused, find, etc. Seems that even when the ByteString is immediately split and then converted to Strings, it's faster. I may try to push ByteStrings out into more of git-annex gradually, although I suspect most of the time-critical parts are already covered now, and many of the rest rely on libraries that only support Strings.
* Sped up unused.Gravatar Joey Hess2011-09-29
| | | | | | | | | | | | | Added Git.ByteString which replaces Git IO methods with ones using lazy ByteStrings. This can be more efficient when large quantities of data are being read from git. In Git.LsTree, parse git ls-tree output more efficiently, thanks to ByteString. This benchmarks 25% faster, in a benchmark that includes (probably predominately) the run time for git ls-tree itself. In real world numbers, this makes git annex unused 2 seconds faster for each branch it needs to check, in my usual large repo.
* releasing version 3.201109283.20110928Gravatar Joey Hess2011-09-28
|
* documentation/warning message update for future featureGravatar Joey Hess2011-09-23
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 17:28:20 +0000