Golden rule of rebase

[spoerri]

Could change ids make it safer and easier than git to rebase published branches?

https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing

[martinvonz]

Yes! Once Change IDs are preserved across push/pull, it will be easy to automatically rebase commits from the old commit onto the new when you pull a rewritten commit from somewhere. This is very similar to what Mercurial's Changeset Evolution feature does, and it lets us (I'm a Mercurial developer) rewrite commits in shared repos without much issue.

This question is very much related to #111, which I filed just 2 days ago. I need to implement that feature first, which will provide some nice improvements even before Change IDs are propagated on push/pull.

The bigger issue is how to propagate Change IDs on push/pull. As I mentioned in #111, that can be done by including the Change ID in the commit message itself like Gerrit does with its Change-Id: footer in the commit message. That solution just requires buy-in from the repo maintainers (so they're not annoyed with you for including that in the commit message). A longer-term solution is to pass them in a header in the commit metadata itself, but for that to be useful with Git repos, we need existing Git tooling (the git CLI tool, JGit, libgit2, etc.) to preserve these headers.

[spoerri]

Thanks! Exciting!

[joyously]

@martinvonz
There was a question about splitting and combining changes in Pijul, and I mentioned that it seems that jj is all about that. I could be mistaken, though, because the Pijul author claims that Git limits jj and

The use case "patch commutation" is explicitly not understood by the author.

Is jj modifying history or limited by Git?

[arxanas]

I'll give my own thoughts and Martin can correct my understanding :)

• jj is not an extension to Git, but it is Git-compatible and snapshot-based.
• Patches in jj could be thought of as being stored symbolically as a pair of tree objects indicating the old and new versions of the code. The patch is derived information. Thus, you could losslessly stack and commute a bunch of patches without losing information, although the result of applying/interpreting those patches may not be useful (i.e. have conflicts). You could argue that this is a rigorous definition of merging, just maybe not a practically useful one.
  • jj is still not as fine-grained as Pijul when storing patches. For example, there is no directive to indicate that a range of bytes moved from one position to another. If I understand correctly, this means that there are categories of conflict which Pijul can handle automatically, but require manual resolution in jj.
• Actually, I lied in the previous point, because I believe that jj will attempt to textually apply patches during a rebase. If a patch applies cleanly, its old pair of trees is effectively discarded and replaced with the new pair. Only conflicting patches are stored symbolically. But it probably would be possible to store all patches symbolically, if desired.
  • Because of this, all descendant commits are also rebased and reapplied in the same way, so history is"rewritten", but I think it's not a fundamental constraint?
• Regardless of the soundness of its patch commutation, jj is pretty good at splitting and combining patches.

[joyously]

jj is still not as fine-grained as Pijul when storing patches.

This is actually a good thing. Pijul stores too much information. When I import the WordPress Git repo, which is about 136Meg, it is over 1Gig in Pijul. It is unmanageable.

all descendant commits are also rebased and reapplied in the same way, so history is"rewritten"

This is the question I have about jj, whether the history of the original commit is still available or gone. It seems to be gone in Pijul. I suppose if you force push, it could be gone in Git as well. But the undo command in jj is there...

[martinvonz]

This is the question I have about jj, whether the history of the original commit is still available or gone. It seems to be gone in Pijul. I suppose if you force push, it could be gone in Git as well. But the undo command in jj is there...

Since we don't have support for GC yet (#12), commits are kept forever. When we implement GC, we'll almost definitely make that preserve all commits reachable from all operations since some given operation. We might let the user say jj gc --keep-from-op=<operation id>, maybe selecting an operation from 3 months ago by default. That'll be similar to what Git does. Git's GC uses the reflogs (which I think means that it can discard recent commits if the branch that pointed to them has been deleted, for example, since reflogs are deleted when the ref is deleted).

[arxanas]

This is the question I have about jj, whether the history of the original commit is still available or gone

You might be asking whether it's an implementation detail or by design that the original commit is still available. In jj, the history of all commits is intended to be tracked in the operation log, and it's intended that it should possible to restore the repository to any previous state (or perhaps just restore an individual commit). This is in contrast with e.g. Git's reflog, where undo is fairly haphazard and sometimes impossible using just the saved information.