FR: Transfer change ids via Git remote

[sheremetyev]

Is your feature request related to a problem? Please describe.
At the moment separate clones of the same Git repository (e.g. on different machines) may have different "change id" for the same commit. Lack of (reliable) stable identifier for commits across clones makes it hard to refer to them.

Describe the solution you'd like
When commit is first pushed to a git remote, its change id should be stored on the remote. When commit is first pulled into another clone, change id should be read from remote as well and used. For commits initially pushed with vanilla Git something reasonable should be done :)

Describe alternatives you've considered
Refer to commits using hashes - works only if commit content hasn't changed.

Additional context
N/A

[joyously]

If the algorithm for computing the change ID results in the same ID from the commit regardless of remote or local, there is no reason to store jj data in a Git remote.

[martinvonz]

The change id is initially generated in a deterministic way but then it follows the commit as it's rewritten, so later versions of the change will not have a change id that can be determined from the commit id.

[edwintorok]

Could 'git notes' be used to store 'change ids'?

[martinvonz]

They were unil commit c260fea

[edwintorok]

Perhaps the conversion from the current storage format to git notes could be done lazily on git push/fetch?

[arxanas]

[long-term] One approach is to somehow synchronize the operation log instead of change IDs directly.

• You could imagine a special branch/ref that jj could push/pull as part of some command, which represents the operation log data.
  • In the Git model, it's possible to design special "op-log commits" such that when they're pulled, they also pull the referenced commits, via an abuse of the parentage mechanism.
  • This would be an important design point because Git doesn't necessarily allow you to fetch arbitrary objects by hash, unless they're reachable by some ref, or some server config option is set (I forget what). It's also relevant for garbage collection purposes.
• This would also help in the "distributed rewrites" case, where one person rewrites commits that another person is building on in a way that wouldn't be handled by just synchronizing change IDs.
  • Or it can be the same person but in different repos, like the original request.

However, it doesn't seem realistic in the near-term due to a significant amount of design and implementation work.