Point module path at this fork - #25
Merged
Merged
Conversation
The module was still declared as github.com/ankitpokhrel/jira-cli, so every internal import resolved through the upstream path and the release ldflags targeted upstream's version package.
rethab
added a commit
that referenced
this pull request
Aug 5, 2026
`go.mod` still declared the module as `github.com/ankitpokhrel/jira-cli`, so this fork's own packages were all imported through the upstream path. Anyone `go install`-ing or importing from `rethab/jira-cli` would get a module whose declared path disagrees with where it actually lives, and the two would be treated as separate modules if both ended up in one build graph. The build configs hardcoded the same path, which is the part that could ship broken silently: the `-X` ldflags in `Makefile` and `.goreleaser.yml` inject version/commit into `internal/version`, and a `-X` against a package path that isn't in the binary is a no-op rather than an error. Left as-is after a module rename, releases would build fine and report an empty version. Verified by building through the Makefile and confirming `jira version` still reports the injected values. README badges and links to upstream discussions/issues are deliberately untouched — those point at the upstream project's community, not at code, and are a separate call to make.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
go.modstill declared the module asgithub.com/ankitpokhrel/jira-cli, so this fork's own packages were all imported through the upstream path. Anyonego install-ing or importing fromrethab/jira-cliwould get a module whose declared path disagrees with where it actually lives, and the two would be treated as separate modules if both ended up in one build graph.The build configs hardcoded the same path, which is the part that could ship broken silently: the
-Xldflags inMakefileand.goreleaser.ymlinject version/commit intointernal/version, and a-Xagainst a package path that isn't in the binary is a no-op rather than an error. Left as-is after a module rename, releases would build fine and report an empty version. Verified by building through the Makefile and confirmingjira versionstill reports the injected values.README badges and links to upstream discussions/issues are deliberately untouched — those point at the upstream project's community, not at code, and are a separate call to make.