respond and close
This commit is contained in:
parent
701f8cb00b
commit
1a8087ace5
2 changed files with 14 additions and 0 deletions
|
@ -51,3 +51,4 @@ git-annex: fsck: 1 failed
|
||||||
### 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)
|
||||||
git-annex helps me keep my sanity :)
|
git-annex helps me keep my sanity :)
|
||||||
|
|
||||||
|
> [[notabug|done]] per comments --[[Joey]]
|
||||||
|
|
|
@ -0,0 +1,13 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 4"""
|
||||||
|
date="2020-03-02T18:54:05Z"
|
||||||
|
content="""
|
||||||
|
As yes, I missed that you also had an example of fsck --key as well as fsck
|
||||||
|
of a file in the working tree with a dead key.
|
||||||
|
|
||||||
|
I think the same basic reasoning applies for fsck --key as for fscking a
|
||||||
|
worktree file. The user appears to be particularly interested in that key,
|
||||||
|
so fsck should tell them about the obious problem that it has no remaining
|
||||||
|
content. It's not like --all.
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue