There seems to be a bug in the code that is not picking up commits with multiple lines.
When I run the git command used to describe the commit, I do not get an error, but the body is ignored as implied by the formatting function (%s only containing the subject).

Impact

Crucial information may be missing from changelogs, including but not limited to message body and footers (possibly containing ticket refs and information about breaking changes).

Current behavior

Given a commit message with a body matching the convetional commit spec
WHEN I run changeset-conventional
THEN an error is logged: fatal: No tags can describe 'sha1'.
THEN the change is not added as changeset

Expected behavior

Given a commit message with a body matching the convetional commit spec
WHEN I run changeset-conventional
THEN the change is added as changeset

How to reproduce

Add a commit message as allowed by the conventional commit spec.

Add a commit to your repo with the following content:

feat(scope): a commit subject

Add a body paragraph to explain the change.

Follow by a second paragraph as allowed by the conventional
commit spec.

Refs: #123

Possible fix

Replace %s token in the git pretty format with %B to retrieve the unwrapped message body instead of the message subject.

Hi 👋

First of all, let me thank you in advance for your for making this a public npm package.

My question is probably better suited to the pull request that served as the basis for this package. Nevertheless, is there a reason why this package purposely drops private packages?

In my use case, I have a set of private packages from which I'd like to generate a changeset based on the conventional commits pattern.

when I tried to run npx changeset-conventional-commits
it does nothing there

Hi, thanks for your great project.
While trying to set up changesets and conventional commits we discovered that there is one issue that may or may not be intentional that is breaking the changelog (for us).

When creating a PR with multiple comits we want to run changeset-conventional to create the changesets and add a comit to the PR. This works great, however, the only reference the changelogs have is the commit when the changesets have been added.

This means that if there is a PR that deals with multiple workspaces and dependency updates the log is not very helpful. The format used may drop essential information.

There are multiple options, depending on how far you want to go. I could also take a stab at implementing if you are willing to accept PRs. I have just briefly looked into the code and maybe this change is not necessary, given the has is already in the returned object. Basically we want to be able to generate a changelog like this:

[**scope**](link-to-repository?id=commitHash): feat: some message

The git command here could be updated to either be configurable or by default add all information to the changelog. This could open the tokens up to be used by a formatter - or simply return the message with the hash included (snas the regex magic) and use a changeset custom log format to do this.

const commitsWithMessages = commitsSinceBase.map((commitHash) => {
  const commitMessage = execSync(`git log -n 1 --pretty=format:%s\n\n%b ${commitHash}`)
  const [,type, scope, breaking, subject, body] = commitMessage.match(/([^(:]+)(?:\(([^)]+)\))?(!)?: (.+)(?:\n{2,}([\s\S]+))?/))
  return {
    commitData: { type, scope, breaking, subject, body },
    commitHash,
    commitMessage: 
  }
});

Let me know if I should elaborate more.

I'm not sure if I'm doing this correctly. I'm using npm running npx changeset-conventional does nothing really.

I'm looking at integrating this into the release flow for a new monorepo I'm working on.

I generated the changesets once locally, but then deleted them all (still working on the bugs of the workflow). But then when I run pnpm dlx changeset-conventional-commits again, I don't get anything generated...

Is this expected behavior? (Or maybe I'm doing something stupid?)