bugfix: Pass --full-tree when using git ls-files to get a list of files on the git-annex branch, so it works when run in a subdirectory. This bug affected git-annex unused, and potentially also transitions running code and other things.
This commit is contained in:
parent
c9c63b092e
commit
174da80ddc
4 changed files with 23 additions and 0 deletions
|
@ -27,3 +27,5 @@ arch linux x86_64
|
|||
### Please provide any additional information below.
|
||||
|
||||
The S3 remote is encrypted with the default "hybrid" method
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,16 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2015-07-06T18:00:53Z"
|
||||
content="""
|
||||
Analysis: To find the keys, it's using git ls-tree git-annex. When this is
|
||||
run in a subdirectory, it only lists files in the branch located under that
|
||||
subdirectory. Which is no files. It should pass --full-tree to avoid that
|
||||
problem.
|
||||
|
||||
Pretty much everywhere git-annex uses ls-tree, it does pass --full-tree.
|
||||
But not in this particular case. Anything using Annex.Branch.branchFiles or
|
||||
Annex.Branch.files would be affected; that's limited to git-annex unused
|
||||
and code that runs transitions. git-annex unused w/o --from could also be
|
||||
affected, I think, perhaps it's harder to trigger that though.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue