Description
The message for jj git fetch should contain info about which remote was fetched to make diagnosing why a jj git fetch in a repo isn't doing what you expected. This is particularly important when users use other tools like gh, which by default renames origin to upstream when you fork. This makes a formerly working command stop working with not visible way to understand why.
I'd suggest two fixes:
- display the remote name in the output message
- display clearer diagnostic info in the debug log (e.g.
git.fetch not set, fetching from "origin" as the default remote)
Steps to Reproduce the Problem
- jj git fetch
- jj git fetch --debug
Expected Behavior
Nothing changed message should clearly show which remotes were checked, which would make it clear that my expectation (upstream) was not what actually happened (origin).
Actual Behavior
❯ jj git fetch
Nothing changed.
❯ jjgf --debug
2026-01-11T02:00:30.348418Z INFO jj_cli::cli_util: debug logging enabled
2026-01-11T02:00:30.365746Z DEBUG run_command:cmd_git_fetch:fetch{remote_name=RemoteName("origin") bookmark_expr=Intersection(Pattern(Glob(GlobPattern("*"))), NotIn(NotIn(Pattern(Substring(""))))) remaining_refspecs=[RefSpec { forced: true, source: Some("refs/heads/*"), destination: "refs/remotes/origin/*" }] negative_refspecs=[] depth=None fetch_tags_override=None}: jj_lib::git_subprocess: spawning a git subprocess cmd=LC_ALL="C" "git" "-c" "core.fsmonitor=false" "-c" "submodule.recurse=false" "--git-dir" "/Users/joshka/local/jj/.git" "fetch" "--prune" "--no-write-fetch-head" "--progress" "--" "origin" "+refs/heads/*:refs/remotes/origin/*"
2026-01-11T02:00:30.850837Z DEBUG run_command:cmd_git_fetch:import_refs: jj_lib::git: import_refs
Nothing changed.
This debug message is too noisy - the info that this is fetching from origin is in there, but why this is so (setting / defaults) is not specified and it requires parsing a fairly complex debug log to work out.
Specifications
- Platform: macos
- Version: 0.37
Description
The message for
jj git fetchshould contain info about which remote was fetched to make diagnosing why a jj git fetch in a repo isn't doing what you expected. This is particularly important when users use other tools like gh, which by default renames origin to upstream when you fork. This makes a formerly working command stop working with not visible way to understand why.I'd suggest two fixes:
git.fetchnot set, fetching from "origin" as the default remote)Steps to Reproduce the Problem
Expected Behavior
Nothing changed message should clearly show which remotes were checked, which would make it clear that my expectation (upstream) was not what actually happened (origin).
Actual Behavior
This debug message is too noisy - the info that this is fetching from origin is in there, but why this is so (setting / defaults) is not specified and it requires parsing a fairly complex debug log to work out.
Specifications