Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
a4lg opened this issue Dec 9, 2022 · 16 comments
Labels
area-rebase-editor Issues or features related to the Interactive Rebase Editor feature New feature or request
Milestone

Comments

@a4lg
Copy link

a4lg commented Dec 9, 2022

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)
@a4lg a4lg added feature New feature or request triage Needs to be looked at labels Dec 9, 2022
@eamodio eamodio removed the triage Needs to be looked at label Dec 11, 2022
@eamodio eamodio added this to the Soon™ milestone Dec 11, 2022
@NathanCQC
Copy link

Any update on this? Would be epic.

@yeroc
Copy link

yeroc commented Feb 16, 2024

Also looking for this!

@d13 d13 added the area-rebase-editor Issues or features related to the Interactive Rebase Editor label Mar 4, 2024
@borisghidaglia
Copy link

Hello 👋
Any news on this?

@eamodio
Copy link
Member

eamodio commented Mar 20, 2024

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

@borisghidaglia
Copy link

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
Copy link
Member

eamodio commented Mar 20, 2024

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
Copy link

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

@borisghidaglia
Copy link

@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
Copy link

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
Copy link
Member

eamodio commented Mar 23, 2024

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

@borisghidaglia
Copy link

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

@borisghidaglia
Copy link

borisghidaglia commented Mar 27, 2024

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.

editor text

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
Copy link

thezwap commented Jul 22, 2024

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
Copy link

ederst commented Oct 30, 2024

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 pushed a commit to thezwap/vscode-gitlens that referenced this issue Nov 1, 2024
This adds a feature to the interactive rebase
editor to support the use of the --update-refs
flag with git interactive rebase command.
gitkraken#2387
@thezwap
Copy link

thezwap commented Nov 1, 2024

I've created (#3705) for this. This is my first PR, so hopefully I've done things correctly.

@thezwap
Copy link

thezwap commented Dec 19, 2024

How do I get the PR reviewed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-rebase-editor Issues or features related to the Interactive Rebase Editor feature New feature or request
Projects
None yet
Development

No branches or pull requests

8 participants