summaryrefslogtreecommitdiff
path: root/Annex/Branch.hs
Commit message (Collapse)AuthorAge
* --in can now refer to files that were located in a repository at some past ↵Gravatar Joey Hess2014-02-06
| | | | date. For example, --in="here@{yesterday}"
* remove debug printGravatar Joey Hess2014-01-26
| | | | just saw it legitimately occur when 2 git-annex were running
* avoid needing a build-dep on hxt for Data.AssocListGravatar Joey Hess2014-01-14
|
* Fix a long-standing bug that could cause the wrong index file to be used ↵Gravatar Joey Hess2014-01-14
| | | | when committing to the git-annex branch, if GIT_INDEX_FILE is set in the environment. This typically resulted in git-annex branch log files being committed to the master branch and later showing up in the work tree. (These log files can be safely removed.)
* Avoid using git commit in direct mode, since in some situations it will read ↵Gravatar Joey Hess2013-12-01
| | | | | | | | | | | | the full contents of files in the tree. The assistant's commit code also always avoids git commit, for simplicity. Indirect mode sync still does a git commit -a to catch unstaged changes. Note that this means that direct mode sync no longer runs the pre-commit hook or any other hooks git commit might call. The git annex pre-commit hook action for direct mode is however explicitly run. (The assistant already ran git commit with hooks disabled, so no change there.)
* Ensure that core.sharedrepository is honored when creating the .git/annex ↵Gravatar Joey Hess2013-11-18
| | | | directory.
* Ensure execute bit is set on directories when core.sharedrepsitory is set.Gravatar Joey Hess2013-11-18
|
* typoGravatar Joey Hess2013-11-06
|
* Fix exception handling bug that could cause .git/annex/index to be used for ↵Gravatar Joey Hess2013-11-06
| | | | git commits outside the git-annex branch. Known to affect git-annex when used with the git shipped with Ubuntu 13.10.
* repair command: add handling of git-annex branch and indexGravatar Joey Hess2013-10-23
|
* Automatically and safely detect and recover from dangling ↵Gravatar Joey Hess2013-10-03
| | | | .git/annex/index.lock files, which would prevent git from committing to the git-annex branch, eg after a crash.
* rename confusing functionGravatar Joey Hess2013-10-03
| | | | | The index.lck file is not a lock file. Kept the historical name for now as changing it would be work.
* ensure that commitBranch is only called when the journal is lockedGravatar Joey Hess2013-10-03
| | | | | This is not strictly a requirement, since it does not actually update the journal. But it's a nice invariant to enforce.
* use types to partially prove correctness of journal locking codeGravatar Joey Hess2013-10-03
| | | | | | | | | | | | | | My implementation does not guard against double locking of the journal. But it does ensure that the journal is always locked when operated on, by using a type that is only produced by lockJournal, and which is required as a parameter of all functions that operate on the journal. Note that I had to add the fooStale functions for cases where it does not make sense to lock the journal when querying it. I was more concerned about ensuring that anything that modifies the journal is locked. setJournalFile's implementation ensures that any query of the journal will get one value or the other atomically, even if the journal is being changed at the time.
* lockJournal when running performTransitionsGravatar Joey Hess2013-10-03
| | | | | | | This may not strictly be needed -- the transition code bypasses the journal. However, this ensures that the git-annex branch is only committed with the journal locked. This will allow for further improvements.
* avoid double commit during transitionGravatar Joey Hess2013-09-03
| | | | | | The second commit had some bad refs which resulted in the race detection code running. But that commit was unnecessary anyway, it only was there to merge in the other refs.
* forget --drop-dead: Completely removes mentions of repositories that have ↵Gravatar Joey Hess2013-08-31
| | | | | | | | | | | | | been marked as dead from the git-annex branch. Wrote nice pure transition calculator, and ugly code to stage its results into the git-annex branch. Also had to split up several Log modules that Annex.Branch needed to use, but that themselves used Annex.Branch. The transition calculator is limited to looking at and changing one file at a time. While this made the implementation relatively easy, it precludes transitions that do stuff like deleting old url log files for keys that are being removed because they are no longer present anywhere.
* remove printGravatar Joey Hess2013-08-29
|
* wordingGravatar Joey Hess2013-08-29
|
* add forget commandGravatar Joey Hess2013-08-28
| | | | | | | | | Works, more or less. --dead is not implemented, and so far a new branch is made, but keys no longer present anywhere are not scrubbed. git annex sync fails to push the synced/git-annex branch after a forget, because it's not a fast-forward of the existing synced branch. Could be fixed by making git-annex sync use assistant-style sync branches.
* untested transition detection on merging, and transition running codeGravatar Joey Hess2013-08-28
|
* importfeed: git-annex becomes a podcatcher in 150 LOCGravatar Joey Hess2013-07-28
|
* XMPP: Avoid redundant and unncessary pushes. Note that this breaks ↵Gravatar Joey Hess2013-05-21
| | | | compatibility with previous versions of git-annex, which will refuse to accept any XMPP pushes from this version.
* Fix a bug in the git-annex branch handling code that could cause info from a ↵Gravatar Joey Hess2013-05-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | remote to not be merged and take effect immediately. This bug was turned up by the test suite, running fsck in direct mode. A repository was cloned, was put into direct mode, was fscked, and fsck incorrectly said that no copy existed of a file, that was actually present in origin. This turned out to occur because fsck first did a Annex.Branch.change, recording that it did not locally have the file. That was recorded in the journal. Since neither the git annex direct not the fsck had yet needed to read any info from the branch, but had only made changes to it, the origin/git-annex branch was not yet merged in. So the journal got a location log entry written to it, but this did not include the location log info for the origin. When fsck then did a Annex.Branch.get, it trusted the journal was cosnsitent, and returned it, again w/o merging from origin/git-annex. This latter behavior is the actual bug. Refer to commit e9bfa8eaed3ff59a4c0bc8d4d677bc493177807c for the thinking behind it being ok to make a change to a file on the branch, without first merging the branch. That thinking still stands. However, it means that files in the journal cannot be trusted to be consistent if the branch has not been merged. So, to fix, just enure the branch gets merged, even when reading from the journal. In tests, this does not seem to cause any extra merging. Except, of course, in the one case described above. But git annex add, etc, are able to make changes w/o first merging the branch.
* fix android build, broken by changes for windows portGravatar Joey Hess2013-05-16
|
* fix permission damage (thanks, Windows)Gravatar Joey Hess2013-05-11
|
* clean up from windows portingGravatar Joey Hess2013-05-11
|
* git-annex now builds on Windows (doesn't work)Gravatar Joey Hess2013-05-11
|
* fixup #if 0 stubs to use #ifndef mingw32_HOST_OSGravatar Joey Hess2013-05-10
| | | | | | That's needed in files used to build the configure program. For the other files, I'm keeping my __WINDOWS__ define, as I find that much easier to type. I may search and replace it to use the mingw32_HOST_OS thing later.
* stub out POSIX stuffGravatar Joey Hess2013-05-10
|
* hlintGravatar Joey Hess2013-04-03
|
* git subcommand cleanupGravatar Joey Hess2013-03-03
| | | | | | Pass subcommand as a regular param, which allows passing git parameters like -c before it. This was already done in the pipeing set of functions, but not the command running set.
* Makefile now builds using cabal, taking advantage of cabal's automatic ↵Gravatar Joey Hess2013-02-27
| | | | | | | | | detection of appropriate build flags. The only thing lost is ./ghci Speed: make fast used to take 20 seconds here, when rebuilding from touching Command/Unused.hs. With cabal, it's 29 seconds.
* work around broken getEnvironment on Android in the most important place: ↵Gravatar Joey Hess2013-02-22
| | | | | | | | git annex init This resulted in a lot of user complains that git annex init had git telling them they needed to run git config --global user.email .. which didn't work because even HOME was not passed into git.
* whitespace fixesGravatar Joey Hess2012-12-13
|
* finished where indentation changesGravatar Joey Hess2012-12-13
|
* remove git-annex branch read cacheGravatar Joey Hess2012-10-19
| | | | | | | | | | | | | This cache prevented noticing changes made by another process. The case I just ran into involved the assistant dropping a file, which cached its presence info. Then the same file was downloaded again, but the assistant didn't know its presence info had changed. I don't see a way to keep this cache. Will instead rely on the OS level file cache, for files in the journal. May need to add more higher-level caching of info that it's ok to have a potentially stale copy of, although much of git-annex already does so.
* Avoid unsetting HOME when running certian git commands. Closes: #690193Gravatar Joey Hess2012-10-11
| | | | | | | | | | | | Setting GIT_INDEX_FILE clobbers the rest of the environment, making git not read ~/.gitconfig, and blow up if GECOS didn't have a name for the user. I'm not entirely happy with getEnvironment being run every time now, that's somewhat expensive. It may make sense to just set GIT_COMMITTER_* and GIT_AUTHOR_*, but I worry that clobbering the rest could break PATH, or GIT_PATH, or something else that might be used by a command run in here. And caching the environment is not a good idea either; it can change..
* fix last zombies in the assistantGravatar Joey Hess2012-10-04
| | | | | Made Git.LsFiles return cleanup actions, and everything waits on processes now, except of course for Seek.
* more zombie fightingGravatar Joey Hess2012-10-04
| | | | | | | | | | | | | | | | | | | | I'm down to 9 places in the code that can produce unwaited for zombies. Most of these are pretty innocuous, at least for now, are only used in short-running commands, or commands that run a set of actions and explicitly reap zombies after each one. The one from Annex.Branch.files could be trouble later, since both Command.Fsck and Command.Unused can trigger it, and the assistant will be doing those eventally. Ditto the one in Git.LsTree.lsTree, which Command.Unused uses. The only ones currently affecting the assistant though, are in Git.LsFiles. Several threads use several of those. (And yeah, using pipes or ResourceT would be a less ad-hoc approach, but I don't really feel like ripping my entire code base apart right now to change a foundation monad. Maybe one of these days..)
* flip catchDefaultIOGravatar Joey Hess2012-09-17
|
* bugfix: avoid staging but not committing changes to git-annex branchGravatar Joey Hess2012-09-15
| | | | | | | | | | | | | | | | | | | | | | Branch.get is not able to see changes that have been staged to the index but not committed. This is a limitation of git cat-file --batch; when reading from the index, as opposed to from a branch, it does not notice changes made after the first time it reads the index. So, had to revert the changes made in 1f73db3469e29448bcb1520893de11b23da6fb1f to make annex.alwayscommit=false stage changes. Also, ensure that Branch.change and Branch.get always see changes at all points during a commit, by not deleting journal files when staging to the index. Delete them only after committing the branch. Before, there was a race during commits where a different git-annex could see out-of-date info from the branch while a commit was in progress. That's also done when updating the branch to merge in remote branches. In the case where the local git-annex branch has had changes pushed into it that are not yet reflected in the index, and there are journalled changes as well, a merge commit has to be done.
* eliminate some commits to the git-annex branchGravatar Joey Hess2012-09-15
| | | | | | | | | | | | | | Commits used to be made to the git-annex branch whenever there were journalled changes from a previous command, and the current command looked up the value of a file. This no longer happens. This means that transferkey, which is a oneshot command that stages changes, can be run multiple times by the assistant, without each of them committing the changes made by the command before. Which will be a lot faster and use less space by batching up the commits. Commits still happen if a remote git-annex branch has been changed and is merged in.
* remove withIndexUpdate helperGravatar Joey Hess2012-09-15
|
* thread safe git-annex index file useGravatar Joey Hess2012-08-24
|
* avoid unnecessary transfer scans when syncing a disconnected remoteGravatar Joey Hess2012-08-22
| | | | | | | | | | | | | | | | | | | | Found a very cheap way to determine when a disconnected remote has diverged, and has new content that needs to be transferred: Piggyback on the git-annex branch update, which already checks for divergence. However, this does not check if new content has appeared locally while disconnected, that should be transferred to the remote. Also, this does not handle cases where the two git repos are in sync, but their content syncing has not caught up yet. This code could have its efficiency improved: * When multiple remotes are synced, if any one has diverged, they're all queued for transfer scans. * The transfer scanner could be told whether the remote has new content, the local repo has new content, or both, and could optimise its scan accordingly.
* hlintGravatar Joey Hess2012-06-12
|
* refactor and function name cleanupGravatar Joey Hess2012-06-08
| | | | (oops, I had a calcMerge and a calc_merge!)
* close the git add raceGravatar Joey Hess2012-06-06
| | | | | | | | | | | | | | | | | There's a race adding a new file to the annex: The file is moved to the annex and replaced with a symlink, and then we git add the symlink. If someone comes along in the meantime and replaces the symlink with something else, such as a new large file, we add that instead. Which could be bad.. This race is fixed by avoiding using git add, instead the symlink is directly staged into the index. It would be nice to make `git annex add` use this same technique. I have not done so yet because it currently runs git update-index once per file, which would slow does `git annex add`. A future enhancement would be to extend the Git.Queue to include the ability to run update-index with a list of Streamers.
* factor out generic update-index code from unionmerge codeGravatar Joey Hess2012-06-06
|