Full disclosure: This is entirely LLM-generated and an attempt to fix #299 based on what I think the best solution is.

This seems like a pretty major conceptual refactor. It seems simple and cleaner to add a new config option that's basically a template for the root path, which defaults to ${hostname}/, or something?

It's not just about the hostname, the path of the repository must be properly constructed. A template won't help here, as you can see from the broken path in the example.

surely something would - like a config object where you specify path as /foo/bar/ vs the default /?

I think you're suggesting some configurable template for the host, but that does not help when the repository oath is wrongly constructed. Please look at the unit test cases and see how they fail today. You wouldn't want users having to specify the exact remote path naming convention per repository, and it's not even necessary, because the suggested change handles that automatically for everyone.

Just to comment on this a bit more: I think there may be a misunderstanding about where the bug is.

The git remote URL itself already contains the full path. remote.pathname from parse-github-url gives us /foo/bar/baz/project correctly. There is no need for the user to configure anything. The auto-changelog tool currently just throws that information away in the fallback branch by using remote.repo (first two segments only).

So it's not that the tool can't know the path; it's that it's discarding what it already knows.

A config option would work, but every self-hosted GitLab user with nested groups gets broken commit URLs unless they discover the option and set it for every single repository.

The added test cases pin the existing platforms to their correct output so there's no regression risk.

i'm confused, then why do we need to make github (or "not github") special? we should just always use remote.pathname for every case, no?

You're right – I tested it and there's actually no reason for a special case. Rebased and simplified.