Add support for `git update -i --update-refs` (Interactive rebase editor, Git 2.38)

[a4lg]

Git 2.38 added the --update-refs option to git rebase.

For instance, assume following repository:

      [feat1]       [feat2]       [feat3,HEAD]
F11 <- F12 <- F21 <- F22 <- F31 <- F32
 |
 v
C01 <- C02 <- C03
             [main]

and we are on the feat3 branch.

If we run regular git rebase main command, the result will be:

      [feat1]       [feat2]
F11 <- F12 <- F21 <- F22 <- F31 <- F32
 |
 v
C01 <- C02 <- C03
             [main]
               ^
               |
              F11'<- F12'<- F21'<- F22'<- F31'<- F32'
                                                [feat3,HEAD]

On the other hand, if we run new git rebase --update-refs main command (new in Git 2.38), the result will be:

                    [feat1]       [feat2]       [feat3,HEAD]
              F11'<- F12'<- F21'<- F22'<- F31'<- F32'
               |
               v
C01 <- C02 <- C03
             [main]

As you notice, not just feat3 branch, intermediate references feat1 and feat2 are updated.

If we run the command git rebase -i --update-refs main, the default git-rebase-todo will look like this:

pick 8032d32f9d20 F11
pick 8a722d15209f F12
update-ref refs/heads/feat1

pick 632047524e9d F21
pick 16ed45fce9aa F22
update-ref refs/heads/feat2

pick 4c831d0f2851 F31
pick 0273bfae21d8 F32

Note that, git-rebase-todo file will have some update-ref lines by default, not just picks (when git rebase -i --update-refs is run and a reference to update is found). It would be nice if we can safely manage update-ref lines (not to break intermediate references/checkpoints).

Some of my thoughts follow:

• Tier 1 (Interactive Rebase Editor)
  • Able to display update-ref entries on the interactive rebase editor (just like other lines like pick? or with a special appearance?)
  • Able to indirectly reorder update-ref entries (through reordering other lines)
• Tier 2 (Interactive Rebase Editor)
  • Able to drop update-ref entries if necessary
  • Able to directly reorder update-ref entries
• Tier 3 (Support with other UI elements / actions)

[NathanCQC]

Any update on this? Would be epic.

[yeroc]

Also looking for this!

[borisghidaglia]

Hello 👋 Any news on this?

[eamodio]

Unfortunately this isn't on our short-term roadmap. Would someone like to open a pull request to get it started?

[borisghidaglia]

Thanks for answering so quickly 🙏 Do you think it's something tricky or rather something doable for someone who doesn't know the codebase? I work as a freelance so I might be able to try between contracts.

[eamodio]

At first blush it doesn't seem to tricky to meet Tier 1 (or Tier 2) above, since it should be largely internal to the rebase editor.

Here is the extension host side ("server") of the rebase editor: https://github.com/gitkraken/vscode-gitlens/blob/01fa090c9359831ce54f8c52734da5b689ce4b31/src/webviews/rebase/rebaseEditor.ts

Here is the webview side ("app") of the rebase editor: https://github.com/gitkraken/vscode-gitlens/blob/9e709d706a7581647b69123c76cadc6fb9897a83/src/webviews/apps/rebase/rebase.ts

[borisghidaglia]

Thanks for the hints, I'll have a look!

[borisghidaglia]

@eamodio I had no problem to build, watch and even package the extension. Super nice that it worked with 0 effort👌

However, from the contributing file, I don't understand the development workflow. What I'm looking for is a way to watch for changes and have these changes applied to the GitLens extension in VSCode.

Today, I have to run yarn package, wait for it to run and then manually install the new .vsix from the VSCode UI.

Did I miss something?

[borisghidaglia]

Ok I understand now. I did this which I didn't realize was not only useful for debugging but also to manually try things in the UI.

When I wanted to open a test folder, VSCode opened it in a new window where GitLens wasn't available, though. I used code -r <path> to open my test folder in the current window, but I had to look for it. Maybe something worth adding to the contributing file?

[eamodio]

I've updated the CONTRIBUTING docs with some more details -- do they help?

[borisghidaglia]

Yes they do, thanks! Here is what I think would be best. If you like these changes I'll open a PR :)

[borisghidaglia]

Tier 1 in progress! I'll have to make it pretty, now.

I took way too much time for so few changes, but 🤷🏻‍♂️ For now I added | update-ref: ${ref} after the commit message.

---

About Tier 2 I understand that you could drop an update-ref entry, but what would "directly reorder[ing]" it mean? Could you move it anywhere along your commits? Also, what would the UX look like? I don't think I have a good enough git understanding to be super relevant here.

About Tier 3 Today, the rebasing flow is the following:

1. Choosing a branch to rebase onto
2. Select if we want a regular rebase or an interactive one

How should we implement the update-refs flag selection?

• By adding a step 3 with two choices (update-refs or not)?
• By adding two more choices right inside step 2 (so the choices would be: rebase, rebase interactive, rebase --update-refs, rebase interactive --update-refs)?

[thezwap]

Is this PR still being worked on? If not, I thought I might have a go.

Personally, I think any update-ref line in the git-rebase-todo file, should be represented as it's own line in the editor, that can be dragged up or down, like the commits. By placing the update-ref after a commit, you are effectively saying "move the pointer for this branch to include all commits before it."

[ederst]

Personally, I think any update-ref line in the git-rebase-todo file, should be represented as it's own line in the editor, that can be dragged up or down, like the commits. By placing the update-ref after a commit, you are effectively saying "move the pointer for this branch to include all commits before it."

Yep, this is actually useful when stacking branches: https://adamj.eu/tech/2022/10/15/how-to-rebase-stacked-git-branches/#add-changes-to-stacked-branches

[thezwap]

I've created (https://github.com/gitkraken/vscode-gitlens/pull/3705) for this. This is my first PR, so hopefully I've done things correctly.