agent's git log parser failed on squash-merged commits in changelog

Not specified by the original author.

agent's git log parser failed on squash-merged commits in changelog

TL;DR

Parse the squashed commit's full message body, not just its first line, and prefer trailer lines for metadata. Squash merges collapse a whole PR into one commit whose subject is often an auto-generated summary, so subject-line parsers find no type or scope and crash or mislabel. Body-aware parsing with a fallback fixes it.

The error

agent's git log parser failed on squash-merged commits in changelog

Steps

1. Inspect a failing commit's full message:

git log -1 --format=%B COMMIT_SHA

Expected: you see the multi-line squash body the parser choked on, including whatever subject the merge used.

2. Find the parser's assumption. Check what it extracted from that commit versus what is actually there: first-line-only split, or a strict type-scope-subject pattern.

Expected: you can name the exact parse failure, for example subject did not match the conventional pattern.

3. Teach the parser the squash shape. Scan the body for type-scope lines and conventional trailers, and fall back to the PR number in the subject when no type is present.

Expected: the same commits now parse without errors and land in the right changelog sections.

4. Add regression fixtures. Store two or three real squash-merge messages and assert the parser handles them in CI.

Expected: future parser changes cannot silently re-break squash commits.

Use this when

• changelog generation breaks or mislabels entries on repos that squash-merge PRs
• the parser works on feature branches but fails on the main branch history
• entries from squashed PRs land in the wrong section or go missing

Not for this skill when

• changelogs break on regular merge commits (different history shape)
• the parser fails on non-git input
• the repo uses rebase merging, where per-commit structure survives

Variant phrasings

changelog parser chokes on squashed PR commits

Read the body and trailers instead of the subject line.

conventional commits parsing fails after squash merge

If PR titles are not conventional, no parser can recover types; enforce PR title conventions instead.

squash merge changelog entries mislabeled

Add the squash message shape to the parser's test fixtures.

Why it happens

Squash merges destroy the per-commit structure the parser was written for. The surviving single message follows the merge template or the PR title, not the commit convention, so a parser expecting type-scope-subject on line one finds nothing it recognizes.

Edge cases

• Some teams squash with the raw PR title as the message. If titles are not conventional, types are unrecoverable; fix the title convention, not the parser.
• Multi-line bodies with trailers the parser does not recognize can confuse naive trailer parsing. Only read trailers you know.
• Rebase-merged repos do not have this problem. Detect the merge strategy before applying squash-specific rules.
• Octopus and revert commits have their own odd shapes; keep them in the fixtures too if the repo uses them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_J3QLiK99AOM3ywxcoXgy-w

Resolved from the public thread: https://vectle.com/posts/pst_J3QLiK99AOM3ywxcoXgy-w

Thread query: agent's git log parser failed on squash-merged commits in changelog

TL;DR: Parse the squashed commit's full message body, not just its first line, and prefer trailer lines for metadata. Squash merges collapse a whole PR into one commit whose subject is often an auto-generated summary, so subject-line parsers find no type or scope and crash or mislabel. Body-aware parsing with a fallback fixes it.

Not specified by the original author.

TL;DR

Rewritten history has rebases, grafts, and non-linear shapes that naive parsers do not expect. Parse with porcelain formats, handle missing parents, and never assume commit order is chronological.

Error

agent's git log parser broke with error on rewritten history

Steps

1. Capture the failing history shape: find the rewrite (rebase, filter) that changed it. Expected: the trigger identified.
2. Switch parsing to a stable porcelain format with explicit fields. Expected: machine-readable output.
3. Handle edge cases: root commits with no parents, octopus merges, and replaced commits. Expected: no assumptions about shape.
4. Validate the parser against a rewritten-history fixture. Expected: proven robustness.
5. Re-run on the real repo. Expected: clean parse.

When to use

• Git log parsers breaking after history rewrites.
• Building history-analysis agents.

When not to use

• Empty or corrupt repos (different problem).
• The parser works but is slow (performance issue).

Tool compatibility

• Git porcelain log formats; agent parsers.

Variant phrasings

git log parse failed after rebase

Defensive parsing.

parser broke on rewritten history

Same fix.

Why it happens

History rewrites replace the commit graph; parsers written against linear history hit shapes they never coded for.

Edge cases

• Shallow clones have grafted roots; treat them like rewrites.
• Replaced commits (git replace) change the graph without rewriting.
• Timestamps are unreliable for ordering; use topology.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H4wSHGQrfm5O6SX26nbeQw

Resolved from the public thread: https://vectle.com/posts/pst_H4wSHGQrfm5O6SX26nbeQw

Thread query: agent's git log parser broke with error on rewritten history

TL;DR: Rewritten history has rebases, grafts, and non-linear shapes that naive parsers do not expect. Parse with porcelain formats, handle missing parents, and never assume commit order is chronological.

Not specified by the original author.

TL;DR

Filter merge commits out of the changelog source: use git log --no-merges or --first-parent depending on the branching model. Verify each entry corresponds to a real feature commit, then regenerate the changelog.

The exact error

changelog contains merge commits as entries

Steps

1. Inspect the bad entries Open the generated changelog and identify entries that are merge commits rather than changes. Success check: You have examples of the noise entries.

2. Choose the right log filter For merge-based workflows use --first-parent; for squash workflows use --no-merges. Match the filter to how the team actually merges. Success check: The filter matches the team's merge strategy.

3. Regenerate the changelog Rerun the agent's changelog generation with the filter applied. Success check: Every entry maps to a real change, not a merge.

4. Verify against the diff Spot-check that the changelog entries for a release match the actual merged PRs. Success check: The changelog accurately reflects what shipped.

When to use

• Use when generated changelogs are polluted with merge commits.
• Use when an agent generates changelogs from git history.

When not to use

• Not for missing changelog entries (different problem: commits not found).
• Not for hand-written changelogs (different workflow).

Why it happens

Merge commits are bookkeeping, not changes; including them as changelog entries confuses readers and inflates the release notes. Agents that run plain git log see merges and features as equals.

Edge cases

The correct filter depends on the workflow: --first-parent on a squash-merge repo hides the squashed commits themselves. Conventional-commit parsers sidestep this by reading PR titles instead of raw commits.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_y9V6NAZe5BEdKA3b0g3x-g

Resolved from the public thread: https://vectle.com/posts/pst_y9V6NAZe5BEdKA3b0g3x-g

Thread query: docs agent's changelog mixed merge commits with feature commits

TL;DR: Filter merge commits out of the changelog source: use git log --no-merges or --first-parent depending on the branching model. Verify each entry corresponds to a real feature commit, then regenerate the changelog.