summaryrefslogtreecommitdiff
path: root/Annex/GitOverlay.hs
Commit message (Collapse)AuthorAge
* Optimisations to git-annex branch query and setting, avoiding repeated ↵Gravatar Joey Hess2016-09-29
| | | | | | | | | | | | | | | | | | | | | | copies of the environment. Speeds up commands like "git-annex find --in remote" by over 50%. Profiling showed that adjustGitEnv was 21% of the time and 37% of the allocations of that command. It copied the environment each time with getEnvironment. The only repeated use of adjustGitEnv is in withIndexFile, which tends to be run at least once per file. So, it was optimised by keeping a cache of the environment, which can be reused. There could be other better ways to optimise this. Maybe get the while environment once at startup. But, then it would have to be serialized back out each time running a child process, so I doubt that would be a net win. It might be better to cache a version of the environment that is pre-modified to use .git-annex/index. But, profiling doesn't show that modifying the enviroment is taking any significant time.
* withAltRepo needs a separate queue of changesGravatar Joey Hess2016-06-03
| | | | | | | | | | | | | | | | | | | | | The queue could potentially contain changes from before withAltRepo, and get flushed inside the call, which would apply the changes to the modified repo. Or, changes could be queued in withAltRepo that were intended to affect the modified repo, but don't get flushed until later. I don't know of any cases where either happens, but better safe than sorry. Note that this affect withIndexFile, which is used in git-annex branch updates. So, it potentially makes things slower. Should not be by much; the overhead consists only of querying the current queue a couple of times, and potentially flushing changes queued within withAltRepo earlier, that could have maybe been bundled with other later changes. Notice in particular that the existing queue is not flushed when calling withAltRepo. So eg when git annex add needs to stage files in the index, it will still bundle them together efficiently.
* git's handing of relative GIT_INDEX_FILE is more insane than I thought; ↵Gravatar Joey Hess2016-05-22
| | | | | | | | | | | | | | | always make absolute This is actually worse than I thought; when git is being run with a detached work tree, GIT_INDEX_FILE is treated as a path relative to CWD, instead of the normal behavior of relative the top of the work tree. This seems to make it basically impossible for any program that wants to use GIT_INDEX_FILE to use anything other than an absolute path to it; there are too many configurations to keep straight that can change how git interprets what should be a simple relative path to a file. (I have complained to the git developers.)
* unify handling of unusual GIT_INDEX_FILE relative pathGravatar Joey Hess2016-05-17
| | | | This is probably a git bug that stuck in its interface.
* use indexEnvGravatar Joey Hess2016-05-17
|
* Work around git bug in handling of relative path to GIT_INDEX_FILE when in a ↵Gravatar Joey Hess2016-05-17
| | | | | | | | 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.
* adjusted branches need git 2.2.0 or newerGravatar Joey Hess2016-04-22
| | | | | | 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.
* avoid withWorkTreeRelated affecting annex symlink calculationGravatar Joey Hess2016-04-08
|
* fix auto merge conflict resolution when doing out of tree merge for adjusted ↵Gravatar Joey Hess2016-04-06
| | | | branch
* new method for merging changes into adjusted branch that avoids unncessary ↵Gravatar Joey Hess2016-04-06
merge conflicts Still needs work when there are actual merge conflicts.