Unsupported extension name

[petrisch]

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

[nickgerace]

Thanks for the report! This looks like a valid bug. I'll take a look when I get the chance.

[petrisch]

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?

[nickgerace]

That does help and I am low on free time. I'm taking a look at 1.0.4. Thanks for the follow up!

[nickgerace]

Usually, I find the most bugs in the "is unpushed" logic. I looked here to start:

gfold/gfold/src/util.rs

Lines 147 to 181 in 9854433

	fn is_unpushed(repo: &git2::Repository, head: &git2::Reference) -> bool {
	let local = match head.peel_to_commit() {
	Ok(local) => local,
	Err(e) => {
	debug!("[-] error: {}", e);
	return false;
	}
	};
	debug!("[+] local commit: {:#?}", local.id());
	if let Some(name) = head.name() {
	debug!("[+] local ref: {}", name);
	}
	let upstream = match repo.resolve_reference_from_short_name("origin") {
	Ok(reference) => {
	if let Some(name) = reference.name() {
	debug!("[+] origin ref: {}", name);
	}
	match reference.peel_to_commit() {
	Ok(upstream) => upstream,
	Err(e) => {
	debug!("[-] error: {}", e);
	return false;
	}
	}
	}
	Err(e) => {
	debug!("[-] error: {}", e);
	return false;
	}
	};
	debug!("[+] origin commit: {:#?}", upstream.id());
	matches!(repo.graph_ahead_behind(local.id(), upstream.id()), Ok(ahead) if ahead.0 > 0)
	}

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.

[petrisch]

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!

[petrisch]

Many thanks for the new version!! 🥳
This one is still a thing, thou thats probably no surprise for you 😄

[nickgerace]

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.

[petrisch]

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)

[nickgerace]

Thanks for that! Wondering if we can catch it alongside fixing #202...

[nickgerace]

I believe #202 was fixed in release 4.1.2. Perhaps, we'll see new behavior relevant to this issue in the new release.

[petrisch]

Hm, unfortunately we are back at this with 4.1.2:
Error: unsupported extension name extensions.worktreeconfig; class=Repository (6)

[nickgerace]

Looking into seeing how we can avoid it... This seems to be an upstream issue: libgit2/libgit2#6044

[nickgerace]

Okay this is where it is failing. I'm going to investigate.

[nickgerace]

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.

[petrisch]

@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 💯

[nickgerace]

Glad to hear! Will keep an eye here: #205 (comment)

[nickgerace]

Looks like this was fixed a few months ago. Going to re-investigate.