Fetching a rebased change-id nukes its evolog

[senekor]

Description

When commits are rebased on a remote with git-replay (for example with GitHub's rebase-merge) and these commits are then fetched again, their previous evolog is nuked.

Steps to Reproduce the Problem

Set git.write-change-id-header = true in your config.

1. create a new repo on Github
2. push a new branch
3. on GitHub, create a PR for that branch and merge it with "rebase merge" (delete the branch to avoid a divergent change-id later)
4. run jj git fetch to fetch the rebased commit
5. run jj evolog -r <change-id>

Expected Behavior

The evolog should include the previous entries from before the rebased commit was fetched.

Actual Behavior

The evolog is nuked and the only entry is the one from the rebased commit, as if it was a completely new one.

Specifications

• Platform: Linux
• Version: jj 0.28.2-fbaa51b4cecb0602fd9ae1e95922e3ab672138dd

[yuja]

Evolution history and change id are separate things as of now. We'll need to either produce fake predecessor links on fetch/import or redesign evolution log to respect operation history.