2014-03-04 20:26:15 +00:00
|
|
|
{- git-annex automatic merge conflict resolution
|
|
|
|
-
|
2016-01-08 19:04:09 +00:00
|
|
|
- Copyright 2012-2016 Joey Hess <id@joeyh.name>
|
2014-03-04 20:26:15 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2014-03-04 20:26:15 +00:00
|
|
|
-}
|
|
|
|
|
2019-12-09 17:49:05 +00:00
|
|
|
{-# LANGUAGE OverloadedStrings #-}
|
|
|
|
|
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
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
2014-03-04 20:26:15 +00:00
|
|
|
import qualified Annex.Queue
|
|
|
|
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
|
2018-05-14 18:22:44 +00:00
|
|
|
import Git.Types (TreeItemType(..), fromTreeItemType)
|
2016-01-05 21:22:19 +00:00
|
|
|
import Git.FilePath
|
2014-03-04 20:26:15 +00:00
|
|
|
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
|
2016-04-14 18:30:15 +00:00
|
|
|
import Utility.FileMode
|
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
|
2016-01-08 19:04:09 +00:00
|
|
|
import qualified Data.ByteString.Lazy as L
|
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
|
|
|
-}
|
2017-06-01 16:46:36 +00:00
|
|
|
autoMergeFrom :: Git.Ref -> Maybe Git.Ref -> [Git.Merge.MergeConfig] -> Annex Bool -> Git.Branch.CommitMode -> Annex Bool
|
|
|
|
autoMergeFrom branch currbranch mergeconfig canresolvemerge 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
|
2019-08-26 19:52:19 +00:00
|
|
|
go old = do
|
2016-05-16 19:11:14 +00:00
|
|
|
r <- inRepo (Git.Merge.merge branch mergeconfig commitmode)
|
2017-06-01 16:46:36 +00:00
|
|
|
<||> (resolvemerge <&&> commitResolvedMerge commitmode)
|
2016-05-16 19:11:14 +00:00
|
|
|
-- Merging can cause new associated files to appear
|
|
|
|
-- and the smudge filter will add them to the database.
|
|
|
|
-- To ensure that this process sees those changes,
|
|
|
|
-- close the database if it was open.
|
|
|
|
Database.Keys.closeDb
|
|
|
|
return r
|
2017-06-01 16:46:36 +00:00
|
|
|
where
|
|
|
|
resolvemerge = ifM canresolvemerge
|
|
|
|
( resolveMerge old branch False
|
|
|
|
, return False
|
|
|
|
)
|
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.
|
|
|
|
-
|
2019-08-26 19:52:19 +00:00
|
|
|
- The merge is resolved in the work tree and files
|
2014-03-04 20:26:15 +00:00
|
|
|
- staged, to clean up from a conflicted merge that was run in the work
|
2016-04-06 21:32:04 +00:00
|
|
|
- tree.
|
|
|
|
-
|
|
|
|
- This is complicated by needing to support merges run in an overlay
|
|
|
|
- work tree, in which case the CWD won't be within the work tree.
|
|
|
|
- In this mode, there is no need to update the work tree at all,
|
|
|
|
- as the overlay work tree will get deleted.
|
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
|
|
|
-}
|
2016-04-06 21:32:04 +00:00
|
|
|
resolveMerge :: Maybe Git.Ref -> Git.Ref -> Bool -> Annex Bool
|
|
|
|
resolveMerge us them inoverlay = do
|
2019-12-09 17:49:05 +00:00
|
|
|
top <- if inoverlay
|
2016-04-06 21:32:04 +00:00
|
|
|
then pure "."
|
|
|
|
else fromRepo Git.repoPath
|
2014-03-04 20:26:15 +00:00
|
|
|
(fs, cleanup) <- inRepo (LsFiles.unmerged [top])
|
2016-04-06 21:32:04 +00:00
|
|
|
srcmap <- if inoverlay
|
|
|
|
then pure M.empty
|
|
|
|
else inodeMap $ pure (map LsFiles.unmergedFile fs, return True)
|
|
|
|
(mergedks, mergedfs) <- unzip <$> mapM (resolveMerge' srcmap us them inoverlay) fs
|
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
|
|
|
let mergedks' = concat mergedks
|
|
|
|
let mergedfs' = catMaybes mergedfs
|
|
|
|
let merged = not (null mergedfs')
|
2014-03-04 20:26:15 +00:00
|
|
|
void $ liftIO cleanup
|
|
|
|
|
2019-08-26 19:52:19 +00:00
|
|
|
unless inoverlay $ do
|
2020-05-28 19:55:17 +00:00
|
|
|
(deleted, cleanup2) <- inRepo (LsFiles.deleted [] [top])
|
2014-03-04 20:26:15 +00:00
|
|
|
unless (null deleted) $
|
2015-06-01 17:52:23 +00:00
|
|
|
Annex.Queue.addCommand "rm"
|
|
|
|
[Param "--quiet", Param "-f", Param "--"]
|
2019-12-02 14:51:43 +00:00
|
|
|
(map fromRawFilePath 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
|
2019-08-26 19:52:19 +00:00
|
|
|
unless inoverlay $ do
|
2020-05-28 19:55:17 +00:00
|
|
|
unstagedmap <- inodeMap $ inRepo $
|
|
|
|
LsFiles.notInRepo [] False [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
|
|
|
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
|
|
|
|
|
2016-04-06 21:32:04 +00:00
|
|
|
resolveMerge' :: InodeMap -> Maybe Git.Ref -> Git.Ref -> Bool -> LsFiles.Unmerged -> Annex ([Key], Maybe FilePath)
|
|
|
|
resolveMerge' _ Nothing _ _ _ = return ([], Nothing)
|
|
|
|
resolveMerge' unstagedmap (Just us) them inoverlay u = 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
|
|
|
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.
|
2016-04-06 21:32:04 +00:00
|
|
|
unless inoverlay $
|
|
|
|
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
|
2016-04-14 18:30:15 +00:00
|
|
|
else makepointer keyUs file (combinedmodes)
|
2015-12-29 20:33:06 +00:00
|
|
|
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
|
2016-01-08 19:04:09 +00:00
|
|
|
graftin them file LsFiles.valThem LsFiles.valThem LsFiles.valUs
|
2016-04-14 18:30:15 +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
|
2016-01-08 19:04:09 +00:00
|
|
|
graftin us file LsFiles.valUs LsFiles.valUs 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 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
|
2019-12-02 14:51:43 +00:00
|
|
|
file = fromRawFilePath $ 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
|
|
|
|
2018-05-14 18:22:44 +00:00
|
|
|
islocked select = select (LsFiles.unmergedTreeItemType u) == Just TreeSymlink
|
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
|
|
|
|
2016-04-14 18:30:15 +00:00
|
|
|
combinedmodes = case catMaybes [ourmode, theirmode] of
|
|
|
|
[] -> Nothing
|
|
|
|
l -> Just (combineModes l)
|
|
|
|
where
|
2018-05-14 18:22:44 +00:00
|
|
|
ourmode = fromTreeItemType
|
|
|
|
<$> LsFiles.valUs (LsFiles.unmergedTreeItemType u)
|
|
|
|
theirmode = fromTreeItemType
|
|
|
|
<$> LsFiles.valThem (LsFiles.unmergedTreeItemType u)
|
2016-04-14 18:30: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
|
|
|
makeannexlink key select
|
2015-12-29 20:33:06 +00:00
|
|
|
| islocked select = makesymlink key dest
|
2016-04-14 18:30:15 +00:00
|
|
|
| otherwise = makepointer key dest destmode
|
2015-12-29 20:33:06 +00:00
|
|
|
where
|
|
|
|
dest = variantFile file key
|
2018-05-14 18:22:44 +00:00
|
|
|
destmode = fromTreeItemType <$> select (LsFiles.unmergedTreeItemType u)
|
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
|
|
|
|
2016-04-06 21:32:04 +00:00
|
|
|
stagefile :: FilePath -> Annex FilePath
|
|
|
|
stagefile f
|
2019-12-09 17:49:05 +00:00
|
|
|
| inoverlay = (</> f) . fromRawFilePath <$> fromRepo Git.repoPath
|
2016-04-06 21:32:04 +00:00
|
|
|
| otherwise = pure f
|
|
|
|
|
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
|
2016-04-06 21:32:04 +00:00
|
|
|
unless inoverlay $ replacewithsymlink dest l
|
2019-12-02 14:51:43 +00:00
|
|
|
dest' <- toRawFilePath <$> stagefile dest
|
2016-04-06 21:32:04 +00:00
|
|
|
stageSymlink dest' =<< hashSymlink l
|
2014-03-04 20:26:15 +00:00
|
|
|
|
2016-01-08 19:04:09 +00:00
|
|
|
replacewithsymlink dest link = withworktree dest $ \f ->
|
2020-03-06 15:31:01 +00:00
|
|
|
replaceWorkTreeFile f $ makeGitLink link . toRawFilePath
|
2014-07-08 17:54:42 +00:00
|
|
|
|
2016-04-14 18:30:15 +00:00
|
|
|
makepointer key dest destmode = do
|
2016-04-06 21:32:04 +00:00
|
|
|
unless inoverlay $
|
2017-11-15 20:55:38 +00:00
|
|
|
unlessM (reuseOldFile unstagedmap key file dest) $
|
|
|
|
linkFromAnnex key dest destmode >>= \case
|
2016-04-06 21:32:04 +00:00
|
|
|
LinkAnnexFailed -> liftIO $
|
2019-12-02 14:51:43 +00:00
|
|
|
writePointerFile (toRawFilePath dest) key destmode
|
2016-04-06 21:32:04 +00:00
|
|
|
_ -> noop
|
2019-12-02 14:51:43 +00:00
|
|
|
dest' <- toRawFilePath <$> stagefile dest
|
2016-04-14 18:30:15 +00:00
|
|
|
stagePointerFile dest' destmode =<< hashPointerFile key
|
2016-04-06 21:32:04 +00:00
|
|
|
unless inoverlay $
|
|
|
|
Database.Keys.addAssociatedFile key
|
2019-12-09 17:49:05 +00:00
|
|
|
=<< inRepo (toTopFilePath (toRawFilePath dest))
|
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
|
|
|
|
2019-08-26 19:52:19 +00:00
|
|
|
withworktree f a = a f
|
2016-01-08 19:04:09 +00:00
|
|
|
|
|
|
|
{- Stage a graft of a directory or file from a branch
|
|
|
|
- and update the work tree. -}
|
|
|
|
graftin b item selectwant selectwant' selectunwant = do
|
2014-07-08 17:54:42 +00:00
|
|
|
Annex.Queue.addUpdateIndex
|
|
|
|
=<< fromRepo (UpdateIndex.lsSubTree b item)
|
2016-01-08 19:04:09 +00:00
|
|
|
|
|
|
|
-- Update the work tree to reflect the graft.
|
2018-05-14 18:22:44 +00:00
|
|
|
unless inoverlay $ case (selectwant (LsFiles.unmergedTreeItemType u), selectunwant (LsFiles.unmergedTreeItemType u)) of
|
2016-01-08 19:04:09 +00:00
|
|
|
-- Symlinks are never left in work tree when
|
|
|
|
-- there's a conflict with anything else.
|
|
|
|
-- So, when grafting in a symlink, we must create it:
|
2018-05-14 18:22:44 +00:00
|
|
|
(Just TreeSymlink, _) -> do
|
2016-01-08 19:04:09 +00:00
|
|
|
case selectwant' (LsFiles.unmergedSha u) of
|
|
|
|
Nothing -> noop
|
|
|
|
Just sha -> do
|
|
|
|
link <- catSymLinkTarget sha
|
2019-12-02 14:51:43 +00:00
|
|
|
replacewithsymlink item (fromRawFilePath link)
|
2016-01-08 19:04:09 +00:00
|
|
|
-- And when grafting in anything else vs a symlink,
|
|
|
|
-- the work tree already contains what we want.
|
2018-05-14 18:22:44 +00:00
|
|
|
(_, Just TreeSymlink) -> noop
|
2016-01-08 19:04:09 +00:00
|
|
|
_ -> ifM (withworktree item (liftIO . doesDirectoryExist))
|
|
|
|
-- a conflict between a file and a directory
|
|
|
|
-- leaves the directory, so since a directory
|
|
|
|
-- is there, it must be what was wanted
|
|
|
|
( noop
|
|
|
|
-- probably a file with conflict markers is
|
|
|
|
-- in the work tree; replace with grafted
|
|
|
|
-- file content
|
|
|
|
, case selectwant' (LsFiles.unmergedSha u) of
|
|
|
|
Nothing -> noop
|
|
|
|
Just sha -> withworktree item $ \f ->
|
2020-03-06 15:31:01 +00:00
|
|
|
replaceWorkTreeFile f $ \tmp -> do
|
2016-01-08 19:04:09 +00:00
|
|
|
c <- catObject sha
|
|
|
|
liftIO $ L.writeFile tmp c
|
|
|
|
)
|
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)
|
2019-12-02 14:51:43 +00:00
|
|
|
, inks <$> isAnnexLink (toRawFilePath f)
|
|
|
|
, inks <$> liftIO (isPointerFile (toRawFilePath 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
|
|
|
]
|
|
|
|
| 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
|
|
|
|
|
2019-12-02 14:51:43 +00:00
|
|
|
inodeMap :: Annex ([RawFilePath], IO Bool) -> Annex InodeMap
|
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
|
|
|
inodeMap getfiles = do
|
|
|
|
(fs, cleanup) <- getfiles
|
|
|
|
fsis <- forM fs $ \f -> do
|
2019-12-11 18:12:22 +00:00
|
|
|
mi <- withTSDelta (liftIO . genInodeCache 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
|
|
|
return $ case mi of
|
|
|
|
Nothing -> Nothing
|
2019-12-11 18:12:22 +00:00
|
|
|
Just i -> Just (inodeCacheToKey Strongly i, fromRawFilePath 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
|
|
|
void $ liftIO cleanup
|
|
|
|
return $ M.fromList $ catMaybes fsis
|