2014-03-04 20:26:15 +00:00
|
|
|
{- git-annex automatic merge conflict resolution
|
|
|
|
-
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
- Copyright 2012-2015 Joey Hess <id@joeyh.name>
|
2014-03-04 20:26:15 +00:00
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
2014-07-11 20:45:18 +00:00
|
|
|
module Annex.AutoMerge
|
|
|
|
( autoMergeFrom
|
|
|
|
, resolveMerge
|
2014-07-11 20:59:49 +00:00
|
|
|
, commitResolvedMerge
|
2014-07-11 20:45:18 +00:00
|
|
|
) where
|
2014-03-04 20:26:15 +00:00
|
|
|
|
|
|
|
import Common.Annex
|
|
|
|
import qualified Annex.Queue
|
|
|
|
import Annex.Direct
|
|
|
|
import Annex.CatFile
|
|
|
|
import Annex.Link
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
import Annex.Content
|
2014-03-04 20:26:15 +00:00
|
|
|
import qualified Git.LsFiles as LsFiles
|
|
|
|
import qualified Git.UpdateIndex as UpdateIndex
|
|
|
|
import qualified Git.Merge
|
|
|
|
import qualified Git.Ref
|
|
|
|
import qualified Git
|
2014-07-04 15:36:59 +00:00
|
|
|
import qualified Git.Branch
|
2014-03-04 20:26:15 +00:00
|
|
|
import Git.Types (BlobType(..))
|
|
|
|
import Config
|
|
|
|
import Annex.ReplaceFile
|
|
|
|
import Annex.VariantFile
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
import qualified Database.Keys
|
|
|
|
import Annex.InodeSentinal
|
|
|
|
import Utility.InodeCache
|
2014-03-04 20:26:15 +00:00
|
|
|
|
|
|
|
import qualified Data.Set as S
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
import qualified Data.Map as M
|
2014-03-04 20:26:15 +00:00
|
|
|
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
{- Merges from a branch into the current branch (which may not exist yet),
|
2014-07-05 21:12:05 +00:00
|
|
|
- with automatic merge conflict resolution.
|
|
|
|
-
|
|
|
|
- Callers should use Git.Branch.changed first, to make sure that
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
- there are changes from the current branch to the branch being merged in.
|
2014-07-05 21:12:05 +00:00
|
|
|
-}
|
2015-04-11 04:10:34 +00:00
|
|
|
autoMergeFrom :: Git.Ref -> Maybe Git.Ref -> Git.Branch.CommitMode -> Annex Bool
|
2014-07-04 15:36:59 +00:00
|
|
|
autoMergeFrom branch currbranch commitmode = do
|
2014-03-04 20:26:15 +00:00
|
|
|
showOutput
|
2014-03-04 21:45:11 +00:00
|
|
|
case currbranch of
|
|
|
|
Nothing -> go Nothing
|
|
|
|
Just b -> go =<< inRepo (Git.Ref.sha b)
|
2014-03-04 20:26:15 +00:00
|
|
|
where
|
2014-03-04 21:45:11 +00:00
|
|
|
go old = ifM isDirect
|
2014-07-04 15:36:59 +00:00
|
|
|
( mergeDirect currbranch old branch (resolveMerge old branch) commitmode
|
2015-12-29 20:36:21 +00:00
|
|
|
, inRepo (Git.Merge.mergeNonInteractive branch commitmode)
|
2014-07-04 15:36:59 +00:00
|
|
|
<||> (resolveMerge old branch <&&> commitResolvedMerge commitmode)
|
2014-03-04 21:45:11 +00:00
|
|
|
)
|
2014-03-04 20:26:15 +00:00
|
|
|
|
|
|
|
{- Resolves a conflicted merge. It's important that any conflicts be
|
|
|
|
- resolved in a way that itself avoids later merge conflicts, since
|
|
|
|
- multiple repositories may be doing this concurrently.
|
|
|
|
-
|
2014-03-04 21:45:11 +00:00
|
|
|
- Only merge conflicts where at least one side is an annexed file
|
|
|
|
- is resolved.
|
2014-03-04 20:26:15 +00:00
|
|
|
-
|
|
|
|
- This uses the Keys pointed to by the files to construct new
|
2014-03-04 21:45:11 +00:00
|
|
|
- filenames. So when both sides modified annexed file foo,
|
2014-03-04 20:26:15 +00:00
|
|
|
- it will be deleted, and replaced with files foo.variant-A and
|
|
|
|
- foo.variant-B.
|
|
|
|
-
|
|
|
|
- On the other hand, when one side deleted foo, and the other modified it,
|
|
|
|
- it will be deleted, and the modified version stored as file
|
|
|
|
- foo.variant-A (or B).
|
|
|
|
-
|
|
|
|
- It's also possible that one side has foo as an annexed file, and
|
|
|
|
- the other as a directory or non-annexed file. The annexed file
|
|
|
|
- is renamed to resolve the merge, and the other object is preserved as-is.
|
|
|
|
-
|
|
|
|
- In indirect mode, the merge is resolved in the work tree and files
|
|
|
|
- staged, to clean up from a conflicted merge that was run in the work
|
2014-06-10 00:32:11 +00:00
|
|
|
- tree.
|
2014-06-09 22:01:30 +00:00
|
|
|
-
|
2014-06-10 00:32:11 +00:00
|
|
|
- In direct mode, the work tree is not touched here; files are staged to
|
|
|
|
- the index, and written to the gitAnnexMergeDir, for later handling by
|
|
|
|
- the direct mode merge code.
|
2015-10-15 18:22:46 +00:00
|
|
|
-
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
- Unlocked files remain unlocked after merging, and locked files
|
|
|
|
- remain locked. When the merge conflict is between a locked and unlocked
|
|
|
|
- file, that otherwise point to the same content, the unlocked mode wins.
|
|
|
|
- This is done because only unlocked files work in filesystems that don't
|
|
|
|
- support symlinks.
|
|
|
|
-
|
2015-10-15 18:22:46 +00:00
|
|
|
- Returns false when there are no merge conflicts to resolve.
|
|
|
|
- A git merge can fail for other reasons, and this allows detecting
|
|
|
|
- such failures.
|
2014-03-04 20:26:15 +00:00
|
|
|
-}
|
2014-03-04 21:45:11 +00:00
|
|
|
resolveMerge :: Maybe Git.Ref -> Git.Ref -> Annex Bool
|
|
|
|
resolveMerge us them = do
|
2014-03-04 20:26:15 +00:00
|
|
|
top <- fromRepo Git.repoPath
|
|
|
|
(fs, cleanup) <- inRepo (LsFiles.unmerged [top])
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
srcmap <- inodeMap $ pure (map LsFiles.unmergedFile fs, return True)
|
|
|
|
(mergedks, mergedfs) <- unzip <$> mapM (resolveMerge' srcmap us them) fs
|
|
|
|
let mergedks' = concat mergedks
|
|
|
|
let mergedfs' = catMaybes mergedfs
|
|
|
|
let merged = not (null mergedfs')
|
2014-03-04 20:26:15 +00:00
|
|
|
void $ liftIO cleanup
|
|
|
|
|
|
|
|
unlessM isDirect $ do
|
|
|
|
(deleted, cleanup2) <- inRepo (LsFiles.deleted [top])
|
|
|
|
unless (null deleted) $
|
2015-06-01 17:52:23 +00:00
|
|
|
Annex.Queue.addCommand "rm"
|
|
|
|
[Param "--quiet", Param "-f", Param "--"]
|
|
|
|
deleted
|
2014-03-04 20:26:15 +00:00
|
|
|
void $ liftIO cleanup2
|
|
|
|
|
|
|
|
when merged $ do
|
2015-12-29 21:35:57 +00:00
|
|
|
Annex.Queue.flush
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
unlessM isDirect $ do
|
|
|
|
unstagedmap <- inodeMap $ inRepo $ LsFiles.notInRepo False [top]
|
|
|
|
cleanConflictCruft mergedks' mergedfs' unstagedmap
|
2014-03-04 20:26:15 +00:00
|
|
|
showLongNote "Merge conflict was automatically resolved; you may want to examine the result."
|
|
|
|
return merged
|
|
|
|
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
resolveMerge' :: InodeMap -> Maybe Git.Ref -> Git.Ref -> LsFiles.Unmerged -> Annex ([Key], Maybe FilePath)
|
|
|
|
resolveMerge' _ Nothing _ _ = return ([], Nothing)
|
|
|
|
resolveMerge' unstagedmap (Just us) them u = do
|
|
|
|
kus <- getkey LsFiles.valUs
|
|
|
|
kthem <- getkey LsFiles.valThem
|
2014-03-04 21:45:11 +00:00
|
|
|
case (kus, kthem) of
|
|
|
|
-- Both sides of conflict are annexed files
|
2014-03-05 02:55:40 +00:00
|
|
|
(Just keyUs, Just keyThem)
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
| keyUs /= keyThem -> resolveby [keyUs, keyThem] $ do
|
|
|
|
makeannexlink keyUs LsFiles.valUs
|
|
|
|
makeannexlink keyThem LsFiles.valThem
|
2015-12-29 21:11:28 +00:00
|
|
|
-- cleanConflictCruft can't handle unlocked
|
|
|
|
-- files, so delete here.
|
|
|
|
unless (islocked LsFiles.valUs) $
|
|
|
|
liftIO $ nukeFile file
|
2015-12-29 20:33:06 +00:00
|
|
|
| otherwise -> do
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
-- Only resolve using symlink when both
|
2015-12-29 20:33:06 +00:00
|
|
|
-- were locked, otherwise use unlocked
|
|
|
|
-- pointer.
|
|
|
|
-- In either case, keep original filename.
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
if islocked LsFiles.valUs && islocked LsFiles.valThem
|
2015-12-29 20:33:06 +00:00
|
|
|
then makesymlink keyUs file
|
|
|
|
else makepointer keyUs file
|
|
|
|
return ([keyUs, keyThem], Just file)
|
2014-03-04 21:45:11 +00:00
|
|
|
-- Our side is annexed file, other side is not.
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
(Just keyUs, Nothing) -> resolveby [keyUs] $ do
|
2014-07-08 17:54:42 +00:00
|
|
|
graftin them file LsFiles.valThem LsFiles.valThem
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
makeannexlink keyUs LsFiles.valUs
|
2014-03-04 21:45:11 +00:00
|
|
|
-- Our side is not annexed file, other side is.
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
(Nothing, Just keyThem) -> resolveby [keyThem] $ do
|
2014-07-08 17:54:42 +00:00
|
|
|
graftin us file LsFiles.valUs LsFiles.valUs
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
makeannexlink keyThem LsFiles.valThem
|
2014-03-04 21:45:11 +00:00
|
|
|
-- Neither side is annexed file; cannot resolve.
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
(Nothing, Nothing) -> return ([], Nothing)
|
2014-03-04 20:26:15 +00:00
|
|
|
where
|
|
|
|
file = LsFiles.unmergedFile u
|
2014-03-04 21:45:11 +00:00
|
|
|
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
getkey select =
|
|
|
|
case select (LsFiles.unmergedSha u) of
|
|
|
|
Just sha -> catKey sha
|
|
|
|
Nothing -> return Nothing
|
2014-03-04 21:45:11 +00:00
|
|
|
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
islocked select = select (LsFiles.unmergedBlobType u) == Just SymlinkBlob
|
|
|
|
|
|
|
|
makeannexlink key select
|
2015-12-29 20:33:06 +00:00
|
|
|
| islocked select = makesymlink key dest
|
|
|
|
| otherwise = makepointer key dest
|
|
|
|
where
|
|
|
|
dest = variantFile file key
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
|
2015-12-29 20:33:06 +00:00
|
|
|
makesymlink key dest = do
|
2015-01-27 21:38:06 +00:00
|
|
|
l <- calcRepo $ gitAnnexLink dest key
|
2015-12-29 21:02:14 +00:00
|
|
|
replacewithsymlink dest l
|
2014-03-04 20:26:15 +00:00
|
|
|
stageSymlink dest =<< hashSymlink l
|
|
|
|
|
2015-12-29 21:02:14 +00:00
|
|
|
replacewithsymlink dest link = ifM isDirect
|
2014-07-08 17:54:42 +00:00
|
|
|
( do
|
|
|
|
d <- fromRepo gitAnnexMergeDir
|
2014-07-09 19:39:19 +00:00
|
|
|
replaceFile (d </> dest) $ makeGitLink link
|
|
|
|
, replaceFile dest $ makeGitLink link
|
2014-07-08 17:54:42 +00:00
|
|
|
)
|
|
|
|
|
2015-12-29 20:33:06 +00:00
|
|
|
makepointer key dest = do
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
unlessM (reuseOldFile unstagedmap key file dest) $ do
|
|
|
|
r <- linkFromAnnex key dest
|
|
|
|
case r of
|
|
|
|
LinkAnnexFailed -> liftIO $
|
|
|
|
writeFile dest (formatPointer key)
|
|
|
|
_ -> noop
|
|
|
|
stagePointerFile dest =<< hashPointerFile key
|
|
|
|
Database.Keys.addAssociatedFile key dest
|
|
|
|
|
2014-07-08 17:54:42 +00:00
|
|
|
{- Stage a graft of a directory or file from a branch.
|
|
|
|
-
|
|
|
|
- When there is a conflicted merge where one side is a directory
|
|
|
|
- or file, and the other side is a symlink, git merge always
|
|
|
|
- updates the work tree to contain the non-symlink. So, the
|
|
|
|
- directory or file will already be in the work tree correctly,
|
|
|
|
- and they just need to be staged into place. Do so by copying the
|
|
|
|
- index. (Note that this is also better than calling git-add
|
|
|
|
- because on a crippled filesystem, it preserves any symlink
|
|
|
|
- bits.)
|
|
|
|
-
|
|
|
|
- It's also possible for the branch to have a symlink in it,
|
|
|
|
- which is not a git-annex symlink. In this special case,
|
|
|
|
- git merge does not update the work tree to contain the symlink
|
|
|
|
- from the branch, so we have to do so manually.
|
|
|
|
-}
|
|
|
|
graftin b item select select' = do
|
|
|
|
Annex.Queue.addUpdateIndex
|
|
|
|
=<< fromRepo (UpdateIndex.lsSubTree b item)
|
|
|
|
when (select (LsFiles.unmergedBlobType u) == Just SymlinkBlob) $
|
|
|
|
case select' (LsFiles.unmergedSha u) of
|
|
|
|
Nothing -> noop
|
|
|
|
Just sha -> do
|
2015-12-07 19:22:01 +00:00
|
|
|
link <- catSymLinkTarget sha
|
2015-12-29 21:02:14 +00:00
|
|
|
replacewithsymlink item link
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
|
|
|
|
resolveby ks a = do
|
2014-03-04 21:45:11 +00:00
|
|
|
{- Remove conflicted file from index so merge can be resolved. -}
|
2015-06-01 17:52:23 +00:00
|
|
|
Annex.Queue.addCommand "rm"
|
|
|
|
[Param "--quiet", Param "-f", Param "--cached", Param "--"] [file]
|
2014-03-04 21:45:11 +00:00
|
|
|
void a
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
return (ks, Just file)
|
2014-03-04 20:26:15 +00:00
|
|
|
|
|
|
|
{- git-merge moves conflicting files away to files
|
2014-07-11 20:56:19 +00:00
|
|
|
- named something like f~HEAD or f~branch or just f, but the
|
2014-03-04 20:26:15 +00:00
|
|
|
- exact name chosen can vary. Once the conflict is resolved,
|
|
|
|
- this cruft can be deleted. To avoid deleting legitimate
|
|
|
|
- files that look like this, only delete files that are
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
- A) not staged in git and
|
|
|
|
- B) have a name related to the merged files and
|
|
|
|
- C) are pointers to or have the content of keys that were involved
|
|
|
|
- in the merge.
|
2014-03-04 20:26:15 +00:00
|
|
|
-}
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
cleanConflictCruft :: [Key] -> [FilePath] -> InodeMap -> Annex ()
|
|
|
|
cleanConflictCruft resolvedks resolvedfs unstagedmap = do
|
|
|
|
is <- S.fromList . map (inodeCacheToKey Strongly) . concat
|
|
|
|
<$> mapM Database.Keys.getInodeCaches resolvedks
|
|
|
|
forM_ (M.toList unstagedmap) $ \(i, f) ->
|
|
|
|
whenM (matchesresolved is i f) $
|
2014-03-04 20:26:15 +00:00
|
|
|
liftIO $ nukeFile f
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
where
|
|
|
|
fs = S.fromList resolvedfs
|
|
|
|
ks = S.fromList resolvedks
|
|
|
|
inks = maybe False (flip S.member ks)
|
|
|
|
matchesresolved is i f
|
|
|
|
| S.member f fs || S.member (conflictCruftBase f) fs = anyM id
|
|
|
|
[ pure (S.member i is)
|
|
|
|
, inks <$> isAnnexLink f
|
|
|
|
, inks <$> isPointerFile f
|
|
|
|
]
|
|
|
|
| otherwise = return False
|
|
|
|
|
|
|
|
conflictCruftBase :: FilePath -> FilePath
|
|
|
|
conflictCruftBase f = reverse $ drop 1 $ dropWhile (/= '~') $ reverse f
|
|
|
|
|
|
|
|
{- When possible, reuse an existing file from the srcmap as the
|
|
|
|
- content of a worktree file in the resolved merge. It must have the
|
|
|
|
- same name as the origfile, or a name that git would use for conflict
|
|
|
|
- cruft. And, its inode cache must be a known one for the key. -}
|
|
|
|
reuseOldFile :: InodeMap -> Key -> FilePath -> FilePath -> Annex Bool
|
|
|
|
reuseOldFile srcmap key origfile destfile = do
|
|
|
|
is <- map (inodeCacheToKey Strongly)
|
|
|
|
<$> Database.Keys.getInodeCaches key
|
|
|
|
liftIO $ go $ mapMaybe (\i -> M.lookup i srcmap) is
|
|
|
|
where
|
|
|
|
go [] = return False
|
|
|
|
go (f:fs)
|
|
|
|
| f == origfile || conflictCruftBase f == origfile =
|
|
|
|
ifM (doesFileExist f)
|
|
|
|
( do
|
|
|
|
renameFile f destfile
|
|
|
|
return True
|
|
|
|
, go fs
|
|
|
|
)
|
|
|
|
| otherwise = go fs
|
2014-06-10 00:32:11 +00:00
|
|
|
|
2014-07-04 15:36:59 +00:00
|
|
|
commitResolvedMerge :: Git.Branch.CommitMode -> Annex Bool
|
|
|
|
commitResolvedMerge commitmode = inRepo $ Git.Branch.commitCommand commitmode
|
|
|
|
[ Param "--no-verify"
|
2014-06-10 00:32:11 +00:00
|
|
|
, Param "-m"
|
|
|
|
, Param "git-annex automatic merge conflict fix"
|
|
|
|
]
|
automatic conflict resolution for v6 unlocked files
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.
2015-12-29 19:41:09 +00:00
|
|
|
|
|
|
|
type InodeMap = M.Map InodeCacheKey FilePath
|
|
|
|
|
|
|
|
inodeMap :: Annex ([FilePath], IO Bool) -> Annex InodeMap
|
|
|
|
inodeMap getfiles = do
|
|
|
|
(fs, cleanup) <- getfiles
|
|
|
|
fsis <- forM fs $ \f -> do
|
|
|
|
mi <- withTSDelta (liftIO . genInodeCache f)
|
|
|
|
return $ case mi of
|
|
|
|
Nothing -> Nothing
|
|
|
|
Just i -> Just (inodeCacheToKey Strongly i, f)
|
|
|
|
void $ liftIO cleanup
|
|
|
|
return $ M.fromList $ catMaybes fsis
|