mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

avoid redundant freezeContent call

Browse source 
This opens the potential for the object file to be in place but
git-annex is interrupted before it can freeze it. git-annex fsck already
fixes that situation, which can also occur when lockContentForRemoval
thaws content.

Also improve comment to not be Windows-specific.
This commit is contained in:
Joey Hess 2021-10-27 14:11:34 -04:00
parent 0db7297f00
commit 669037862a
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 28 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/todo/__91__PATCH__93___Call_freezeContent_after_move_into_annex.mdwn
View file

@ -37,3 +37,5 @@ index da65143ab..89c36e612 100644
2.30.2
```
> [[applied|done]] --[[Joey]]

18
doc/todo/__91__PATCH__93___Call_freezeContent_after_move_into_annex/comment_3_ab15af768ade06cd4805763391419524._comment Normal file
View file

@ -0,0 +1,18 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2021-10-27T17:56:15Z"
content="""
Ah, making your script smart is reasonable enough.
I hope you might consider sharing the script in a tip?
Looking at your updated patch, you now leave the freezeContent call before it
moves to the object file, and add another call afterwards. I think that would
be objectionable if the user has a freeze hook that is expensive
the run, because it would unncessarily run twice. I fairly well satisfied
myself in comment #1 that it's ok to defer freezeContent to after it's
moved the object file into place.
So, I've applied it, but modified to remove that earlier freezeContent.
"""]]