simplify
This commit is contained in:
parent
41b7c5f6aa
commit
cc44813550
1 changed files with 14 additions and 70 deletions
|
@ -207,35 +207,17 @@ These changes would need to be committed to the adjusted branch, otherwise
|
|||
|
||||
[WORKTREE: Simply adjust the work tree (and index) per the filter.]
|
||||
|
||||
## reverse filtering
|
||||
## reverse filtering commits
|
||||
|
||||
Reversing filter #1 would mean only converting pointer files to
|
||||
symlinks when the file was originally a symlink. This is problimatic when a
|
||||
file is renamed. Would it be ok, if foo is renamed to bar and bar is
|
||||
committed, for it to be committed as an unlocked file, even if foo was
|
||||
originally locked? Probably.
|
||||
A user's commits on the adjusted branch have to be reverse filtered
|
||||
to get changes to apply to the master branch.
|
||||
|
||||
Reversing filter #2 would mean not deleting removed files whose content was
|
||||
not present. When the commit includes deletion of files that were removed
|
||||
due to their content not being present, those deletions are not propigated.
|
||||
When the user deletes an unlocked file, the content is still
|
||||
present in annex, so reversing the filter should propigate the file
|
||||
deletion.
|
||||
This reversal of one filter can be done as just another filter.
|
||||
Since only files touched by the commit will be reverse filtered, it doesn't
|
||||
need to reverse all changes made by the original filter.
|
||||
|
||||
What if an object was sent to the annex (or removed from the annex)
|
||||
after the commit and before the reverse filtering? This would cause the
|
||||
reverse filter to draw the wrong conclusion. Maybe look at a list of what
|
||||
objects were not present when applying the filter, and use that to decide
|
||||
which to not delete when reversing it?
|
||||
|
||||
So, a reverse filter may need some state that was collected when running
|
||||
the filter forwards, in order to decide what to do.
|
||||
|
||||
Alternatively, instead of reverse filtering the whole adjusted tree,
|
||||
look at just the new commit that's being propigated back from the
|
||||
adjusted to master branch. Get the diff from it to the previous
|
||||
commit; the changes that were made. Then de-adjust those changes,
|
||||
and apply the changes to the master branch.
|
||||
For example, reversing the unlock filter might lock the file. Or, it might
|
||||
do nothing, which would make all committed files remain unlocked.
|
||||
|
||||
## push
|
||||
|
||||
|
@ -304,58 +286,20 @@ adjusting filter, albeit an extreme one. This might improve view branches.
|
|||
For example, it's not currently possible to update a view branch with
|
||||
changes fetched from a remote, and this could get us there.
|
||||
|
||||
This would need the reverse filter to be able to change metadata.
|
||||
This would need the reverse filter to be able to change metadata,
|
||||
so that a commit that moved files in the view updates their metadata.
|
||||
|
||||
[WORKTREE: Wouldn't be able to integrate, unless view branches are changed
|
||||
into adjusted view worktrees.]
|
||||
|
||||
## filter interface
|
||||
|
||||
Distilling all of the above, the filter interface needs to be something
|
||||
like this, at its most simple:
|
||||
|
||||
data Filter = UnlockFilter | HideMissingFilter | UnlockHideMissingFilter
|
||||
|
||||
getFilter :: Annex Filter
|
||||
|
||||
setFilter :: Filter -> Annex ()
|
||||
|
||||
data FilterAction
|
||||
= UnchangedFile FilePath
|
||||
| UnlockFile FilePath
|
||||
| HideFile FilePath
|
||||
|
||||
data FileInfo = FileInfo
|
||||
{ originalBranchFile :: FileStatus
|
||||
, isContentPresent :: Bool
|
||||
}
|
||||
|
||||
data FileStatus = IsAnnexSymlink | IsAnnexPointer
|
||||
deriving (Eq)
|
||||
|
||||
filterAction :: Filter -> FilePath -> FileInfo -> FilterAction
|
||||
filterAction UnlockFilter f fi
|
||||
| originalBranchFile fi == IsAnnexSymlink = UnlockFile f
|
||||
filterAction HideMissingFilter f fi
|
||||
| not (isContentPresent fi) = HideFile f
|
||||
filterAction UnlockHideMissingFilter f fi
|
||||
| not (isContentPresent fi) = HideFile f
|
||||
| otherwise = filterAction UnlockFilter f fi
|
||||
filterAction _ f _ = UnchangedFile f
|
||||
|
||||
filteredCommit :: Filter -> Git.Commit -> Git.Commit
|
||||
|
||||
-- Generate a version of the commit made on the filter branch
|
||||
-- with the filtering of modified files reversed.
|
||||
unfilteredCommit :: Filter -> Git.Commit -> Git.Commit
|
||||
|
||||
## TODOs
|
||||
|
||||
* Need a better command-line interface than `git annex adjust`,
|
||||
that allows picking adjustments.
|
||||
* Interface in webapp to enable adjustments.
|
||||
* Entering an adjusted branch can race with commits to the current branch,
|
||||
and so the assistant should not be running, or at least should have
|
||||
commits disabled when entering it.
|
||||
* Entering an adjusted branch can prevent commits to the current branch
|
||||
(locking will cause the commits to fail) and so the assistant
|
||||
should not be running, or at least should have commits disabled
|
||||
when entering it.
|
||||
* When the adjusted branch unlocks files, behave as if annex.addunlocked is
|
||||
set, so git annex add will add files unlocked.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue