Fix nasty reversion in the last release that broke sync --content's handling of many preferred content expressions.

The type checker should have noticed this, but the changes to mapM
that make it accept any Traversable hid the fact that it was not being
passed a list at all. Thus, what should have returned an empty list most
of the time instead returned [""] which was treated as the name of the
associated file, with disasterout consequences.

When I have time, I should add a test case checking what sync --content
drops. I should also consider replacing mapM with one re-specialized to
lists.
This commit is contained in:
Joey Hess 2016-01-26 14:28:43 -04:00
parent 3ddfa7bf1d
commit 039e83ed5d
Failed to extract signature
5 changed files with 20 additions and 2 deletions

View file

@ -8,6 +8,7 @@
module Annex.Drop where module Annex.Drop where
import Annex.Common import Annex.Common
import qualified Annex
import Logs.Trust import Logs.Trust
import Annex.NumCopies import Annex.NumCopies
import Types.Remote (uuid) import Types.Remote (uuid)
@ -49,7 +50,9 @@ handleDropsFrom :: [UUID] -> [Remote] -> Reason -> Bool -> Key -> AssociatedFile
handleDropsFrom locs rs reason fromhere key afile preverified runner = do handleDropsFrom locs rs reason fromhere key afile preverified runner = do
l <- ifM isDirect l <- ifM isDirect
( associatedFilesRelative key ( associatedFilesRelative key
, mapM getTopFilePath <$> Database.Keys.getAssociatedFiles key , do
g <- Annex.gitRepo
map (`fromTopFilePath` g) <$> Database.Keys.getAssociatedFiles key
) )
let fs = if null l then maybeToList afile else l let fs = if null l then maybeToList afile else l
n <- getcopies fs n <- getcopies fs

View file

@ -86,7 +86,7 @@ performNew file key filemodified = do
repopulate obj repopulate obj
| filemodified = modifyContent obj $ do | filemodified = modifyContent obj $ do
g <- Annex.gitRepo g <- Annex.gitRepo
fs <- mapM (`fromTopFilePath` g) fs <- map (`fromTopFilePath` g)
<$> Database.Keys.getAssociatedFiles key <$> Database.Keys.getAssociatedFiles key
mfile <- firstM (isUnmodified key) fs mfile <- firstM (isUnmodified key) fs
liftIO $ nukeFile obj liftIO $ nukeFile obj

2
debian/changelog vendored
View file

@ -1,5 +1,7 @@
git-annex (6.20160115) UNRELEASED; urgency=medium git-annex (6.20160115) UNRELEASED; urgency=medium
* Fix nasty reversion in the last release that broke sync --content's
handling of many preferred content expressions.
* whereis --json: Urls are now listed inside the remote that claims them, * whereis --json: Urls are now listed inside the remote that claims them,
rather than all together at the end. rather than all together at the end.
* info, add, whereis, find: Support --batch mode. * info, add, whereis, find: Support --batch mode.

View file

@ -16,3 +16,5 @@ git-annex version 6.20160114 on Arch Linux.
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
This behaviour is relatively recent. Until some time ago everything worked as expected with the expression above. This behaviour is relatively recent. Until some time ago everything worked as expected with the expression above.
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2016-01-26T18:22:48Z"
content="""
I think it's worse than that, it lost track of the filename, so
preferred content expressions with include= or exclude= will also do the
wrong thing.
Going to have to rush out a release fixing this..
"""]]