summaryrefslogtreecommitdiff
path: root/Command
Commit message (Collapse)AuthorAge
* rekey: No longer copies over urls from the old to the new key.Gravatar Joey Hess2016-01-07
| | | | | It makes sense for migrate to do that, but not for this low-level (and little used) plumbing command to.
* avoid confusing git with a modified ctime in clean filterGravatar Joey Hess2016-01-07
| | | | | | | Linking the file to the tmp dir was not necessary in the clean filter, and it caused the ctime to change, which caused git to think the file was changed. This caused git status to get slow as it kept re-cleaning unchanged files.
* migrate and rekey v6 unlocked file supportGravatar Joey Hess2016-01-07
|
* migrate: Copy over metadata to new key.Gravatar Joey Hess2016-01-07
|
* unused: deal with v6 unlocked file that is implicitly ingested by git diff etcGravatar Joey Hess2016-01-06
|
* cleanupGravatar Joey Hess2016-01-06
|
* optimiseGravatar Joey Hess2016-01-06
| | | | | | | | | | | | d1ce927d95fe7c331cbff3317797a60aa288738b put a cat-file into the fast bloomfilter generation path. Instead, add another bloom filter which diffs from the work tree to the index. Also, pull the sha of the changed object out of the diffs, and cat that object directly, rather than indirecting through the filename. Finally, removed some hacks that are unncessary thanks to the worktree to index diff.
* fix parsing of v6 unlocked fileGravatar Joey Hess2016-01-06
| | | | The newline broke this ad-hoc parser; use the normal one.
* unused: Bug fix when a new file was added to the annex, and then removed ↵Gravatar Joey Hess2016-01-06
| | | | | | | | (but not git rmed). git still has the add staged in this case, so the content should not be unused and was wrongly treated as such. So, we need to look at both the file on disk to see if it's a annex link, and the file in the index too. lookupFile doesn't look in the index if the file is not present on disk.
* fix test failure locking an unlocked not present fileGravatar Joey Hess2016-01-06
| | | | | | | | In v5, that was not possible, but it is in v6, and so the test was failing. Investigating, it turns out that locking was copying the pointer file content to the annex object despite the content not being present. So, add a check to prevent that.
* whereis --json: Make url list be included in machine-parseable form.Gravatar Joey Hess2016-01-06
|
* use TopFilePath for associated filesGravatar Joey Hess2016-01-05
| | | | | | | | | | | | | | | Fixes several bugs with updates of pointer files. When eg, running git annex drop --from localremote it was updating the pointer file in the local repository, not the remote. Also, fixes drop ../foo when run in a subdir, and probably lots of other problems. Test suite drops from ~30 to 11 failures now. TopFilePath is used to force thinking about what the filepath is relative to. The data stored in the sqlite db is still just a plain string, and TopFilePath is a newtype, so there's no overhead involved in using it in DataBase.Keys.
* info --json: Improve json for "backend usage", using a nested object with ↵Gravatar Joey Hess2016-01-01
| | | | fields for each backend instead of the previous weird nested lists. This may break existing parsers of this json output, if there were any.
* info: Fix "backend usage" numbers, which were counting present keys twice.Gravatar Joey Hess2016-01-01
| | | | Let's just count the referenced keys for that, and not present keys at all.
* switch to using main ingest codeGravatar Joey Hess2016-01-01
| | | | | Fixes at least one bug, in populating existing worktree files that use the same key that's ingested.
* convert isPointerFile from Annex to IOGravatar Joey Hess2016-01-01
|
* don't disable smudge filter while mergingGravatar Joey Hess2015-12-29
| | | | | | | | | | | The smudge filter does need to be run, because if the key is in the local annex already (due to renaming, or a copy of a file added, or a new file added and its content has already arrived), git merge smudges the file and this should provide its content. This does probably mean that in merge conflict resolution, git smudges the existing file, re-copying all its content to it, and then the file is deleted. So, not efficient.
* automatic conflict resolution for v6 unlocked filesGravatar Joey Hess2015-12-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several tricky parts: * When the conflict is just between the same key being locked and unlocked, the unlocked version wins, and the file is not renamed in this case. * Need to update associated file map when conflict resolution renames an unlocked file. * git merge runs the smudge filter on the conflicting file, and actually overwrites the file with the same content it had before, and so invalidates its inode cache. This makes it difficult to know when it's safe to remove such files as conflict cruft, without going so far as to compare their entire contents. Dealt with this by preventing the smudge filter from populating the file when a merge is run. However, that also prevents the smudge filter being run for non-conflicting files, so eg moving a file won't put its new content into place. * Ideally, if a merge or a merge conflict resolution renames an unlocked file, the file in the work tree can just be moved, rather than copying the content to a new worktree file. This is attempted to be done in merge conflict resolution, but due to git merge's behavior of running smudge filters, what actually seems to happen is the old worktree file with the content is deleted and rewritten as a pointer file, so doesn't get reused. So, this is probably not as efficient as it optimally could be. If that becomes a problem, could look into running the merge in a separate worktree and updating the real worktree more efficiently, similarly to the direct mode merge. However, the direct mode merge had a lot of bugs, and I'd rather not use that more error-prone method unless really needed.
* fix file perms after breaking hard linkGravatar Joey Hess2015-12-27
|
* annex.thinGravatar Joey Hess2015-12-27
| | | | | | | | | | | | | | Decided it's too scary to make v6 unlocked files have 1 copy by default, but that should be available to those who need it. This is consistent with git-annex not dropping unused content without --force, etc. * Added annex.thin setting, which makes unlocked files in v6 repositories be hard linked to their content, instead of a copy. This saves disk space but means any modification of an unlocked file will lose the local (and possibly only) copy of the old version. * Enable annex.thin by default on upgrade from direct mode to v6, since direct mode made the same tradeoff. * fix: Adjusts unlocked files as configured by annex.thin.
* add unlocked flag for git-annex-shell recvkeyGravatar Joey Hess2015-12-26
| | | | | | The direct flag is also set when sending unlocked content, to support old versions of git-annex-shell. At some point, the direct flag will be removed, and only the unlocked flag will be used.
* persistent-sqlite is now a hard build dependency, since v6 repository mode ↵Gravatar Joey Hess2015-12-26
| | | | needs it.
* lost some bookkeeping infoGravatar Joey Hess2015-12-24
| | | | I forgot to convert this to use Annex.Ingest, todo later.
* Merge branch 'master' into smudgeGravatar Joey Hess2015-12-22
|\
* | move cleanOldKey into ingestGravatar Joey Hess2015-12-22
| |
* | finish v6 support for assistantGravatar Joey Hess2015-12-22
| | | | | | | | Seems to basically work now!
* | make linkAnnex detect when the file changes as it's being copied/linked inGravatar Joey Hess2015-12-22
| | | | | | | | | | | | | | | | | | This fixes a race where the modified file ended up in annex/objects, and the InodeCache stored in the database was for the modified version, so git-annex didn't know it had gotten modified. The race could occur when the smudge filter was running; now it gets the InodeCache before generating the Key, which avoids the race.
* | refactoringGravatar Joey Hess2015-12-22
| | | | | | | | no behavior changes
| * addurl: Added --with-files option.Gravatar Joey Hess2015-12-22
| |
| * refactorGravatar Joey Hess2015-12-22
| |
* | remove (v6) associated file in unannexGravatar Joey Hess2015-12-21
| |
* | Merge branch 'master' into smudgeGravatar Joey Hess2015-12-21
|\|
| * addurl: Added --batch option.Gravatar Joey Hess2015-12-21
| |
| * status: On crippled filesystems, was displaying M for all annexed files that ↵Gravatar Joey Hess2015-12-19
| | | | | | | | were present. Probably caused by a change to what git status displays in this situation. Fixed by treating files git thinks are modified the same as typechanged files.
* | v6: fix locking modified file when the content is not presentGravatar Joey Hess2015-12-16
| |
* | fix add of file that was locked but has been replaced by a new, unlocked ↵Gravatar Joey Hess2015-12-16
| | | | | | | | file (v6)
* | Use git-annex init --version=6 to get v6 for nowGravatar Joey Hess2015-12-15
| | | | | | | | | | Not ready to make it default because of the direct mode upgrade needing to all happen at once.
* | in v6 mode, unannex does not interact badly with pre-commit hookGravatar Joey Hess2015-12-15
| | | | | | | | So can be used in a tree with staged changes, no problems. Much nicer.
* | recent fsck changes caused ugly message when object was not presentGravatar Joey Hess2015-12-15
| |
* | reorgGravatar Joey Hess2015-12-15
| |
* | changes for v6 broke fsck in direct modeGravatar Joey Hess2015-12-15
| |
* | add: In v6 mode, acts on modified files.Gravatar Joey Hess2015-12-15
| | | | | | | | | | Same as was done in direct mode, except in v6 mode add always adds files locked, so
* | avoid pre-commit check having to do with v5 unlocked files when in v6 modeGravatar Joey Hess2015-12-15
| |
* | rename stuff for v5 unlocked files to indicate it's oldGravatar Joey Hess2015-12-15
| |
* | add: no need to make pass for old unlocked files in v6Gravatar Joey Hess2015-12-15
| |
* | have clean filter check if the filename was already in use by an old keyGravatar Joey Hess2015-12-15
| | | | | | | | | | | | | | | | The annex object for it may have been modified due to hard link, and that should be cleaned up when the new version is added. If another associated file has the old key's content, that's linked into the annex object. Otherwise, update location log to reflect that content has been lost.
* | avoid smudge filter returning invalid contentGravatar Joey Hess2015-12-11
| | | | | | | | | | | | | | | | | | | | | | | | 1. git add file 2. git commit 3. modify file 4. git commit 5. git reset HEAD^ Before this fix, that resulted in git saying the file was modified. And indeed, it didn't have the content it should in the just checked out ref, because step 3 modified the object file for the old key.
* | fsck for v6 unlocked filesGravatar Joey Hess2015-12-11
| | | | | | | | | | | | | | | | This only adds 1 stat to each file fscked for locked files, so added overhead is minimal. For unlocked files it has to access the database to see if a file is modified.
* | finish v6 git-annex lockGravatar Joey Hess2015-12-11
| | | | | | | | This was a doozy!
* | only make 1 hardlink max between pointer file and annex objectGravatar Joey Hess2015-12-11
| | | | | | | | | | | | | | If multiple files point to the same annex object, the user may want to modify them independently, so don't use a hard link. Also, check diskreserve when copying.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-01 11:06:01 +0000