Skip to content

Include dependency type in diff driver and show output#166

Merged
andrew merged 1 commit into
mainfrom
include-dependency-type
May 9, 2026
Merged

Include dependency type in diff driver and show output#166
andrew merged 1 commit into
mainfrom
include-dependency-type

Conversation

@andrew
Copy link
Copy Markdown
Contributor

@andrew andrew commented Mar 10, 2026

The diff driver and the analyzer were not aligned on what constitutes a change. The diff driver output name version without scope, making scope changes invisible in git diffs. Meanwhile the analyzer reported scope-only changes as modified with identical before/after versions (package 1.0.0 -> 1.0.0), which was confusing.

Now both include dependency type. The diff driver outputs name version (scope) so scope changes appear in diffs. The show command displays scope-only changes as package 1.0.0 (dev -> runtime).

Bumps schema to v9 with a previous_dependency_type column on dependency_changes.

Related to #164

@andrew andrew force-pushed the include-dependency-type branch from f215f27 to ad424d7 Compare March 10, 2026 12:29
@benknoble
Copy link
Copy Markdown

Fwiw, I think the format change in the description is worth it. You mentioned being on the fence?

PS I'm now having a hard time passing a commit to git pkgs show; Git revision syntax, abbreviated ids, and full commit ids all give "reference not found." Omitting the commit to show HEAD works fine.

The diff driver now outputs scope (dev, runtime, optional) alongside
name and version so scope changes are visible in git diff. The analyzer
tracks PreviousDependencyType on scope-only changes, and show displays
them as "package 1.0.0 (dev -> runtime)" instead of the misleading
"package 1.0.0 -> 1.0.0".

Bumps schema to v9 with a previous_dependency_type column.

Related to #164
@andrew
Copy link
Copy Markdown
Contributor Author

andrew commented May 7, 2026

Thanks, that tips it. Keeping the format change.

On the show <commit> failure: that's go-git's ResolveRevision, which doesn't implement all of gitrevisions(7). I've opened #193 to fall back to git rev-parse when go-git gives up. Could you give that branch a try?

I couldn't reproduce full SHAs failing locally though, so if #193 doesn't fix it for you I'd be curious what git config extensions.objectformat and git rev-parse --verify <the-sha> say in that repo.

@andrew andrew marked this pull request as ready for review May 7, 2026 15:23
andrew added a commit that referenced this pull request May 9, 2026
go-git's PlainOpen chroots its billy filesystem to .git, so absolute
paths in objects/info/alternates can't be followed and borrowed
objects are invisible. Repos created with clone --shared or
--reference would fail to resolve any SHA in the borrowed history
with "reference not found".

Reopen the storage with AlternatesFS rooted at the volume root so
go-git can follow alternates. PlainOpenOptions doesn't expose this
so the storage has to be rebuilt by hand after discovery.

Reported in #166.
andrew added a commit that referenced this pull request May 9, 2026
go-git's ResolveRevision does not implement reflog (@{n}), :/regex,
date refs, and can fail on hashes in some storage layouts. Shell out
to git rev-parse --verify as a fallback so show/tree/bisect/branch
accept the full gitrevisions(7) grammar.

Reported in #166.
@andrew andrew merged commit d2731eb into main May 9, 2026
7 checks passed
@benknoble
Copy link
Copy Markdown

Ah, by the way, I'm seeing what looks like a bug in consistent/deterministic sorting with the new scope: for example, one hunk in a recent diff looks lole (typing on mobile and copying from a private machine, so forgive me):

A
+B xxx (development)
B xxx (runtime)
-B xxx (development)
B yyy (runtime)
B yyy (runtime)

A and B are packages; xxx and yyy versions.

AFAICT, there is no meaningful diff here either semantically for the dependencies or textually in the lockfile.

@andrew
Copy link
Copy Markdown
Contributor Author

andrew commented May 27, 2026

@benknoble ah good catch, can you open that as a separate issue?

@benknoble
Copy link
Copy Markdown

On the show <commit> failure: that's go-git's ResolveRevision, which doesn't implement all of gitrevisions(7). I've opened #193 to fall back to git rev-parse when go-git gives up. Could you give that branch a try?

[See below: I think that PR is in 0.16.0?]

I couldn't reproduce full SHAs failing locally though, so if #193 doesn't fix it for you I'd be curious what git config extensions.objectformat and git rev-parse --verify <the-sha> say in that repo.

That key is not configured on this repo.

On the flip side, things seem to be working now (on v0.16.0). So I'm not sure what went wrong, or if it was just the fix you mentioned.

andrew added a commit that referenced this pull request May 28, 2026
PR #166 added scope to each output line but the sort comparator still
only considered name and version. When a lockfile lists the same
package and version under more than one scope (e.g. Pipfile.lock
default + develop), those entries compared equal and sort.Slice ordered
them however the parser emitted them, producing spurious diff hunks.

Fixes #217
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants