You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
git fetch: add --rebase to rewrite upstream changes in place
When upstream rewrites a change (e.g. amends or rebases) and you fetch the
new revision, a normal `jj git fetch` keeps your old revision alongside the
new one as a divergent change. With `--rebase`, the incoming revision
rewrites your existing one in place: bookmarks, the working copy, and
descendants are moved onto the new revision, and the old revision is hidden
-- the same outcome jj produces when the rewrite happens locally.
If a change already has multiple visible revisions in the repo before the
fetch, there is no unambiguous old-to-new mapping, so the import aborts with
an error and a hint pointing at `jj abandon` / `jj duplicate`.
`abandon_unreachable_commits` now takes an exclusion set so that commits
already recorded as rewritten don't have their `Rewritten` entry in
`parent_mapping` overwritten with `Abandoned`, which would otherwise
reparent descendants onto the old commit's parents instead of onto the
rewrite target.
git import: rewrite stacks and reject newly-introduced divergence
Address two related gaps in --rebase from the previous commit:
* Stack rebases: `replace_divergent_changes` only iterated head commits, so
when upstream rebased a stack of N changes only the head was paired with
its local counterpart. Now we walk every commit that became newly visible
in jj (head plus newly-imported ancestors, stopping at commits already
reachable from a pre-transaction head) and pair each one's change id.
* Fetch-introduced divergence: when one fetch brought in multiple new
commits sharing a change id with a single existing local commit, the
per-commit loop observed the first new commit as already-visible while
processing the second and aborted with `PreExistingDivergentChange`,
which is misleading. The rewrite logic now groups by change id and
matches old/new candidates by cardinality, and the new
`NewlyDivergentChange` error signals the fetch itself was the source.
git fetch: shift --rebase coverage into lib tests
Move the bulk of --rebase verification out of `cli/tests/test_git_fetch.rs`
(where each case needs a colocated source repo and a full CLI roundtrip) into
`lib/tests/test_git.rs`, which exercises `git::import_refs` directly against a
TestRepo. The CLI-only assertions that lib can't reach — the `Display` for
`GitImportError::DivergentChanges` and the exact contents of each problem's
commit lists — are pinned at the lib level via `err.to_string()` and sorted
commit-id checks. The remote-tracking ref is also asserted in the happy-path
lib test so the rewrite covers both `feat` and `feat@origin`.
A single CLI snapshot remains for the divergent-changes error renderer
(`cli/src/git_util.rs::divergent_changes_error`): it pins the formatted hint
header, the indented commit list rendered through `commit_summary_template`,
and the trailing hint. The pre-existing case is enough — the newly-introduced
path uses the same code with different strings, and those strings are pinned
by the lib `err.to_string()` assertions.
* `--rebase` — Rewrite changes from upstream in place instead of creating divergent changes
1678
+
1679
+
When upstream rewrites a change (e.g. amends or rebases) and you fetch the new revision, the default behavior is to keep your old revision alongside the new one as a divergent change. With `--rebase`, the incoming revision rewrites your existing revision in place: bookmarks, the working copy, and descendants are moved onto the new revision, and the old revision is hidden.
1680
+
1681
+
If upstream rewrites a stack of changes, rewrite mappings are recorded for every change in the stack, not only the head. Aborts if any change is already divergent in your repo before the fetch, or if the fetch itself introduces multiple new revisions for the same change. All such problems are reported in one error so you can resolve them together before retrying.
0 commit comments