gfold
gfold copied to clipboard
nickgerace
Unsupported extension name
Hi
I'm running into this on 4.0.1 with git version 2.37.0.windows.1. The stuff befor this looks good, and I can't figure out, which repo issues this, and if its related to #202
...
[2022-07-28T12:22:46Z DEBUG gfold::report] finalized report collection for repository at path: "\\\\?\\C:\\Users\\**
Error: unsupported extension name extensions.worktreeconfig; class=Repository (6)
0: <unknown>
1: git_trace_set
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: git_trace_set
8: <unknown>
9: <unknown>
10: <unknown>
11: BaseThreadInitThunk
12: RtlUserThreadStart
Thanks for the report! This looks like a valid bug. I'll take a look when I get the chance.
After investing 5min on this, I can only confirm, that the same repo filestructure gives no errors and works on v 1.0.4. This is going back quite a bit, so I don't know if its of any help. I haven't tested any inbetween, maybe next time, or if you could give me a hint?
That does help and I am low on free time. I'm taking a look at 1.0.4. Thanks for the follow up!
Usually, I find the most bugs in the "is unpushed" logic. I looked here to start: https://github.com/nickgerace/gfold/blob/9854433f3aad31a8aaf4ccd0916114c567c7cac3/gfold/src/util.rs#L147-L181
Another place that could be a problem: path canonicalization. I may be pushing a path and then canonicalizing it rather than canonicalizing the initial path.
What's your command invocation look like? I think I see a wild card (*) in your args. I don't believe you need that, but, I should add it to the integration test regardless.
Hm, funny now that you mention it.
I actually did it on C:\Users\username\repo.
And the command used is simply: gfold .
I like the --classic option, but the result was the same. No defence about time necessary btw. I'd love to investigate it myself and understand this pretty well. Just love the tool!
Many thanks for the new version!! 🥳 This one is still a thing, thou thats probably no surprise for you 😄
Yep! I am aware :) Thanks for the reminder @petrisch.
I touched up the integration test code. If it can be reproduced in there, then that would help greatly in fixing the issue. Something I plan to do once I find a larger amount of free coding time.
Just to show still my interest in this, thoug no way I could help further: With 4.1.1 the Error message changed, which might help as well. Haven't done a BACKTRACE though.
Error: no reference found for shorthand 'origin/HEAD'; class=Reference (4); code=NotFound (-3)
I believe #202 was fixed in release 4.1.2. Perhaps, we'll see new behavior relevant to this issue in the new release.
Hm, unfortunately we are back at this with 4.1.2:
Error: unsupported extension name extensions.worktreeconfig; class=Repository (6)
Looking into seeing how we can avoid it... This seems to be an upstream issue: https://github.com/libgit2/libgit2/issues/6044
Alright, I've pinned this issue and marked it as upstream dependent for now. PR #220 should provide a workaround for the time being.
Reproduction Steps
Tested on macOS Ventura 13.1 with git 2.38.1 and gfold 4.1.2. The OS and binaries are native arm64.
REPRODUCTION_DIR=$(mktemp -d)
cd $REPRODUCTION_DIR
git clone --filter=blob:none https://github.com/nickgerace/gfold.git bug
cd bug
git worktree add ../worktree
cd ../worktree
git config extensions.worktreeConfig true
gfold ..
Workaround
- Bad news: I believe affected repositories will need to be skipped for the time being
- Good news: I believe the workaround will prevent gfold from stopping execution
EDIT: the workaround should be available in gfold 4.2.0.
@nickgerace looks like I have never commented on 4.2.0. I can confirm that it works for me again now 👍 And then there is the next version, will have to check that out first maybe ;-)..... and it does 💯
Glad to hear! Will keep an eye here: https://github.com/nickgerace/gfold/issues/205#issuecomment-1362055554