summaryrefslogtreecommitdiff
path: root/Annex/AutoMerge.hs
Commit message (Collapse)AuthorAge
* Fix bad automatic merge conflict resolution between an annexed file and a ↵Gravatar Joey Hess2016-06-07
| | | | | | | directory with the same name when in an adjusted branch. When running in an overlay work tree, all unchanged files show as deleted, so this code that stages deletions should not run.
* move keys db closure to AutoMergeGravatar Joey Hess2016-05-16
| | | | | This makes git-annex sync also do it, which makes sure that the keys db info is fresh when doing a sync --content.
* assistant: Deal with upcoming git's refusal to merge unrelated histories by ↵Gravatar Joey Hess2016-04-22
| | | | | | | | | | | | | default git 2.8.1 (or perhaps 2.9.0) is going to prevent git merge from merging in unrelated branches. Since the webapp's pairing etc features often combine together repositories with unrelated histories, work around this behavior change by setting GIT_MERGE_ALLOW_UNRELATED_HISTORIES when the assistant merges. Note though that this is not done for git annex sync's merges, so it will follow git's default or configured behavior.
* Preserve execute bits of unlocked files in v6 mode.Gravatar Joey Hess2016-04-14
| | | | | | | | | | | | | | When annex.thin is set, adding an object will add the execute bits to the work tree file, and this does mean that the annex object file ends up executable. This doesn't add any complexity that wasn't already present, because git annex add of an executable file has always ingested it so that the annex object ends up executable. But, since an annex object file can be executable or not, when populating an unlocked file from one, the executable bit is always added or removed to match the mode of the pointer file.
* run out of tree merge with --no-ffGravatar Joey Hess2016-04-06
| | | | | | This is how direct mode does it too, and somehow, for reasons that currently escape me, this makes git merge not care if it's run with an empty work tree.
* fix auto merge conflict resolution when doing out of tree merge for adjusted ↵Gravatar Joey Hess2016-04-06
| | | | branch
* remove 163 lines of code without changing anything except importsGravatar Joey Hess2016-01-20
|
* fix one more test failure with v6 unlocked file merge conflict resolutionGravatar Joey Hess2016-01-08
|
* 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.
* convert isPointerFile from Annex to IOGravatar Joey Hess2016-01-01
|
* flush queue before cleaning cruftGravatar Joey Hess2015-12-29
| | | | | | | | | | | Else, queued file stages won't have reached the index, and it won't find everthing. This evidently fixes a reversion in my work today, although I don't see how I broke it. It didn't use to flush the queue first, before, and worked somehow. Test suite for v5 is back to 100% green now.
* test suite noticed a direct mode reversionGravatar Joey Hess2015-12-29
|
* renameGravatar Joey Hess2015-12-29
|
* 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.
* avoid renaming file when auto-resolving conflict in annex pointerGravatar Joey Hess2015-12-29
| | | | | | | | | | This is a behavior change for merge conflicts between locked files that both pointed to the same key, in different ways. Before, the conflict was resolved, but the file was renamed to .variant. This was unnecessary, because there was only one variant. Of course, this also handles conflicts between unlocked and locked, or even two unlocked files with different pointer contents.
* 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.
* support pointer filesGravatar Joey Hess2015-12-07
| | | | | | | | | | | | | | | | | | | | | Backend.lookupFile is changed to always fall back to catKey when operating on a file that's not a symlink. catKey is changed to understand pointer files, as well as annex symlinks. Before, catKey needed a file mode witness, to be sure it was looking at a symlink. That was complicated stuff. Now, it doesn't actually care if a file in git is a symlink or not; in either case asking git for the content of the file will get the pointer to the key. This does mean that git-annex will treat a link foo -> WORM--bar as a git-annex file, and also treats a regular file containing annex/objects/WORM--bar as a git-annex file. Calling catKey could make git-annex commands need to do more work than before. This would especially be the case if a repo contained many regular files, and only a few annexed files, as now git-annex will need to ask git about the contents of the regular files.
* avoid making post-merge-conflict-resolution commit when no conflicts were ↵Gravatar Joey Hess2015-10-15
| | | | | | | | | | resolved sync, merge, assistant: When git merge failed for a reason other than a conflicted merge, such as a crippled filesystem not allowing particular characters in filenames, git-annex would make a merge commit that could omit such files or otherwise be bad. Fixed by aborting the whole merge process when git merge fails for any reason other than a merge conflict.
* remove Params constructor from Utility.SafeCommandGravatar Joey Hess2015-06-01
| | | | | | | | | | | | | | | | | | This removes a bit of complexity, and should make things faster (avoids tokenizing Params string), and probably involve less garbage collection. In a few places, it was useful to use Params to avoid needing a list, but that is easily avoided. Problems noticed while doing this conversion: * Some uses of Params "oneword" which was entirely unnecessary overhead. * A few places that built up a list of parameters with ++ and then used Params to split it! Test suite passes.
* a few hlintsGravatar Joey Hess2015-04-11
|
* Repository tuning parameters can now be passed when initializing a ↵Gravatar Joey Hess2015-01-27
| | | | | | | | | | repository for the first time. * init: Repository tuning parameters can now be passed when initializing a repository for the first time. For details, see http://git-annex.branchable.com/tuning/ * merge: Refuse to merge changes from a git-annex branch of a repo that has been tuned in incompatable ways.
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* resolvemerge: finish up by committingGravatar Joey Hess2014-07-11
|
* Deal with change in git 2.0 that made indirect mode merge conflict ↵Gravatar Joey Hess2014-07-11
| | | | | | | | | | resolution leave behind old files. I think this is a git behavior change, but have not checked to be sure. Conflict cruft used to look like $foo~HEAD, but now just $foo is left behind as conflict cruft. With test case.
* resolvemerge: New plumbing command that runs the automatic merge conflict ↵Gravatar Joey Hess2014-07-11
| | | | resolver.
* fix build warning5.20140709Gravatar Joey Hess2014-07-09
|
* Fix bug in automatic merge conflict resolutionGravatar Joey Hess2014-07-08
| | | | | | | | | | | | | | | | When one side is an annexed symlink, and the other side is a non-annexed symlink. In this case, git-merge does not replace the annexed symlink in the work tree with the non-annexed symlink, which is different from it's handling of conflicts between annexed symlinks and regular files or directories. So, while git-annex generated the correct merge commit, the work tree didn't get updated to reflect it. See comments on bug for additional analysis. Did not add this to the test suite yet; just unloaded a truckload of firewood and am feeling lazy. This commit was sponsored by Adam Spiers.
* assistant: Fix bug, introduced in last release, that caused the assistant to ↵Gravatar Joey Hess2014-07-05
| | | | make many unncessary empty merge commits.
* support commit.gpgsignGravatar Joey Hess2014-07-04
| | | | | | | | | | | | | | | | | | | | | Support users who have set commit.gpgsign, by disabling gpg signatures for git-annex branch commits and commits made by the assistant. The thinking here is that a user sets commit.gpgsign intending the commits that they manually initiate to be gpg signed. But not commits made in the background, whether by a deamon or implicitly to the git-annex branch. gpg signing those would be at best a waste of CPU and at worst would fail, or flood the user with gpg passphrase prompts, or put their signature on changes they did not directly do. See Debian bug #753720. Also makes all commits done by git-annex go through a few central control points, to make such changes easier in future. Also disables commit.gpgsign in the test suite. This commit was sponsored by Antoine Boegli.
* simplifyGravatar Joey Hess2014-06-09
|
* avoid fast-forwarding when a merge conflict was auto-resolvedGravatar Joey Hess2014-06-09
|
* avoid bad commits after interrupted direct mode sync (or merge)Gravatar Joey Hess2014-06-09
| | | | | | | | | | | | | | | It was possible for a interrupted sync or merge in direct mode to leave the work tree out of sync with the last recorded commit. This would result in the next commit seeing files missing from the work tree, and committing their removal. Now, a direct mode merge happens not only in a throwaway work tree, but using a temporary index file, and without any commits or index changes being made until the real work tree has been updated. If the merge is interrupted, the work tree may have some updated files, but worst case a commit will redundantly commit changes that come from the merge. This commit was sponsored by Tony Cantor.
* styleGravatar Joey Hess2014-03-04
|
* sync: Automatically resolve merge conflict between and annexed file and a ↵Gravatar Joey Hess2014-03-04
| | | | | | | | | | | | | | | | | | | regular git file. This is a new feature, it was not handled before, since it's a bit of an edge case. However, it can be handled exactly the same as a file/dir conflict, just leave the non-annexed item alone. While implementing this, the core resolveMerge' function got a lot simpler and clearer. Note especially that where before there was an asymetric call to stagefromdirectmergedir, now graftin is called symmetrically in both cases. And, in order to add that `graftin us`, the current branch needed to be known (if there is no current branch, there cannot be a merge conflict). This led to some cleanups of how autoMergeFrom behaved when there is no current branch. This commit was sponsored by Philippe Gauthier.
* factor out Annex.AutoMerge from Command.SyncGravatar Joey Hess2014-03-04