RFC blog post: "Lightning-fast rebases with git-move"

[arxanas]

Hi all, I've published a blog post outlining git move as a replacement for git rebase here: https://blog.waleedkhan.name/in-memory-rebases/

Please let me know if you have any feedback on this article prior to my publishing to a wider audience.

Also, let me know if you were actually notified about this Discussions post. I don't know if it notifies anyone.

[martinvonz]

I was notified of this discussion. I watch your repo, so that's presumably why. I would think that just starring a repo is not enough to trigger a notification.

The blog post looks good to me. I have several questions, but I don't think they need to be answered in the blog post. They are:

• Do you run any hooks (user-defined ones, not git-branchless-defined ones) from git move? Do you plan to? Which ones?
• Does it support renames and/or copies? If so, did you implement that yourself or were you able to reuse some of Elijah's work?
• You said you're planning to add support for interactive rebase in the future. How will that look? Similar to git rebase -i where you get to edit a plan? (I haven't used git revise so I don't know what that looks like.)

[arxanas]

Thanks for letting me know, and for reviewing the post.

Regarding hooks, see also the discussion on this thread: mystor/git-revise#35. Right now, git-branchless runs the post-rewrite hook, because that's actually how it informs itself that it's rewritten commits. The user's post-rewrite hook may live in the same file. The installation process is hacky: it assumes that the post-rewrite hook, if the user has already defined one, is a Bash script, and then appends its own lines to the end... The better solution would be for Git to come up with the ability to run many user-defined hooks.

Regarding merging, unfortunately, I didn't spend time implementing merge-ort. It seems like it would be great to speed up merge operations, but difficult for me to implement and validate. I just use libgit2's merge machinery, which does rename detection as part of merges, presumably in a less-optimized way. This did require a bit of hacking around libgit2 for monorepo-scaling, since libgit2 operations deal with full indexes instead of sparse indexes. See libgit2/libgit2#6036.

Interactive rebase will probably look like git rebase -i. I'm thinking about whether it makes sense to render an entire tree in the plan, rather than just a stick. The guess the problem is that merge commits would probably be difficult to deal with. I suppose I could just render two entries for the same commit at various places in the tree, rather than come up with a text-editor rendering of a DAG.

git revise offers essentially the same as git rebase -i, but it runs in-memory, and offers some more features, such as cut to split commits and index to manipulate the current changes.

[nasamuffin]

Hi @arxanas, @martinvonz pointed this post out to me and asked me to share some info with you about upcoming changes to Git hooks.

For some time now I've been working on a feature to allow Git to take multiple hook scripts via the config. You can see the original design here: https://lore.kernel.org/git/20210311021037.3001235-2-emilyshaffer@google.com/ (but know that it's somewhat out of date, now - namely, the syntax for your config file would not be the same.) I'm hoping that this feature will end up in Git's 'next' branch by the coming January; another contributor working on it posted a pretty recent status update here: https://lore.kernel.org/git/87lf2yjt3v.fsf@evledraar.gmail.com/

The short version is this: rather than cating more scripts onto the end of an existing post-rewrite hook, you would be able to just specify a second post-rewrite hook for the repo (or, if you think it's more appropriate, for the user's global config).

I'm happy to answer any additional questions you have :)

[arxanas]

@nasamuffin This is exciting work! I'm sure many people, me included, have been long awaiting multiple hooks. Keep me in the loop if anything changes. git-branchless runs CI against Git master and next, so I could start integrating initial support and test it out before the feature's proper release.

[martinvonz]

Regarding hooks, see also the discussion on this thread: mystor/git-revise#35.

Interesting, I didn't realize Git was running hooks so arbitrarily, but that's good news for git-branchless :)

I just use libgit2's merge machinery

Ah, nice. I didn't realize you could do that and get in-memory merging. (That's not an option for jj, though, since it has two backends and the merge code is generic across them.)

Interactive rebase will probably look like git rebase -i

FWIW, I have no plans to add anything like that to jj. I haven't missed it so far. I very rarely use it in Mercurial either.

[arxanas]

I use interactive rebasing all the time... I couldn't live without it. Do you ever need to reorder and combine commits in a stack, and if so, what's your workflow for that?

[martinvonz]

Sorry, I didn't see your question until now. For squashing commits, I use jj squash -r <child commit>. To edit a commit, I generally check it out, make changes and then jj squash. Reordering is the only thing I even slightly miss having interactive rebase for. I currently have to do it using two jj rebase steps.