Add traverse feature

[mkondratek]

[PawelLipski]

Possibly a single button (with a keyboard shortcut!) that would automagically guide the user through the process of syncing the branches, just as git machete traverse does

[PawelLipski]

After ~2 years of using this plugin myself now, I'm skeptical if that's sth we really want in this plugin. That'll probably confuse the hell out of the users, esp. if actions were to happen automatically (equivalent of git machete traverse --yes). Even a semiautomatic guidance (vanilla git machete traverse) seems an overkill TBH... although I'm open to the be convinced otherwise.

[radeusgd]

I've also been using this plugin for almost 2 years and to me it feels (very subjectively) that it could be pretty useful - it makes the process of updating the branches more streamlined, especially if there's more of them.

I'm indeed very skeptical of the --yes mode - this definitely could be confusing. But showing yes/no dialogs, much like the CLI variant does, just in the GUI - I think that would be a cool and quick way to synchronize the worktree after some PR is merged in the upstream. Would be cool if it also included automatic fetch as part of this process too, so that it all can be done in one go.

One thing that traverse does which the GUI does not seem to be able to show currently is detecting that a branch in my tree has got merged into the upstream - if I do git machete traverse I will get a message "The branch X has been merged to Y, do you want to slide it out" (or sth similar) - and this is very helpful. Currently in the GUI, there's no indication of that so I need to 'remember' about this and slide it out myself, manually. Adding traverse could be one way of semi-automating that. Alternatively (or just as a separate, independent cool feature) it would be cool if the 'this branch was probably merged into the parent' could be displayed in the tree structure view.

[PawelLipski]

I've also been using this plugin for almost 2 years and to me it feels (very subjectively) that it could be pretty useful - it makes the process of updating the branches more streamlined, especially if there's more of them.

Okay! that's an input I was waiting for from someone <3 so lemme reconsider including traversal in the plugin indeed

[PawelLipski]

Currently in the GUI, there's no indication of that so I need to 'remember' about this and slide it out myself, manually.

Hmmm could you actually open a separate issue so that we can analyze? Isn't the edge gray between the branches X and Y? 🤔 Pls include screens from plugin and CLI for comparison!

[PawelLipski]

Currently in the GUI, there's no indication of that so I need to 'remember' about this and slide it out myself, manually.

Hmmm could you actually open a separate issue so that we can analyze? Isn't the edge gray between the branches X and Y? thinking Pls include screens from plugin and CLI for comparison!

Just revisited this one... is it still a problem for you @radeusgd after the recent updates? 🤔

[radeusgd]

Currently in the GUI, there's no indication of that so I need to 'remember' about this and slide it out myself, manually.

Hmmm could you actually open a separate issue so that we can analyze? Isn't the edge gray between the branches X and Y? thinking Pls include screens from plugin and CLI for comparison!

Just revisited this one... is it still a problem for you @radeusgd after the recent updates? thinking

I think most of the time the node is correctly gray. I wasn't able to find an easy repro where this didn't work, that's why I gave up (sorry for maybe not mentioning that later on). In most cases when rebasing I still need to drop the commits from the slid-out branch (it is not detected automatically perhaps because we squash upon merge so what is in develop is slightly different from what was in the branch). I feel like the CLI traverse was actually often able to drop these commits automatically - but to be honest I'm not sure if that was ever the case and I was always too lazy to check this. In the end I learnt to appreciate the interactive-rebase-by-default mode of the GUI - as it allows me to clearly see which commits I'm rebasing and be conscious what is to be kept and what is to be dropped, instead of relying on an automatic detection which can make mistakes. There is some cognitive load of having to recognize which is the last commit from the old PR that I want to drop, but in my subjective case this is a small price to pay for the certainty that I'm doing the right thing that an automaton would not provide.

[radeusgd]

As for traverse itself - I got so used to just following a flow: fetch + pull develop + sync my work-branch that I do it without thinking much. Still I feel like an automation which could do all of the above in one click (while still making the sync-by-rebase interactive and asking for confirmation so that I know what is happening) could be helpful - it wouldn't save a lot of time so I'm not sure how much value it provides, but it feels like a neat feature to have a bit less clicking. Especially useful when maintaining multiple feature branches at the same time (which is not very common for me, but for which I think machete is quite optimized as it really shines when the branch structure is more complicated than develop+1 feature branch).

[mkondratek]

In most cases when rebasing I still need to drop the commits from the slid-out branch

that's true!

having:

develop
| 2137xd Add feature
- feature-branch
  | 020897 Fix pipeline
  - fix-branch

after ff merge of feature-branch and sliding it out it often happens that the rebase of fix-branch includes the commit from no longer existing parent ( 2137xd Add feature in the example)

[PawelLipski]

In most cases when rebasing I still need to drop the commits from the slid-out branch

That's a long-standing problem 😅 see git-machete CLI FAQ

[PawelLipski]

Especially useful when maintaining multiple feature branches at the same time (which is not very common for me, but for which I think machete is quite optimized as it really shines when the branch structure is more complicated than develop+1 feature branch).

Exactly, when there's just one branch + develop/main, then the total effort on maintaining the repo with and without git-machete (CLI or plugin) is comparable... it's only with more branches (esp. stacked ones) then the life without git-machete-like tool becomes cumbersome, to put it mildly 😅

[ForsakenHarmony]

I'd love to have an option for automatic "recursive" rebase, this missing feature prevents me from using git-machete

Currently using the graphite CLI to "restack" branches https://docs.graphite.dev/guides/graphite-cli/restacking-branches

gt repo sync > pulls the root branch and checks for merged PRs gt stack restack > rebases everything in the current "stack" starting from the root branch (will delete the merged branches) (gt stack submit > pushes everything in the current "stack" and creates PRs if they don't exist already)

[PawelLipski]

Actually... the traverse feature exists for a long time in git-machete CLI: git machete traverse.

See the gif for the general idea:

This PR aims to migrate that command-line functionality to the IntelliJ plugin.

Trying to objectively compare the features of git machete traverse with what Graphite offers:

gt repo sync > pulls the root branch and checks for merged PRs

Both covered in git-machete, albeit the check is for merged branches; no explicit check for merged PRs (nevertheless, there is git machete github for managing PRs... at least for GitHub now).

gt stack restack > rebases everything in the current "stack" starting from the root branch (will delete the merged branches)

traverse does both; not sure if graphite allows for any trees of branches or just "proper" linear stacks. git-machete allows for arbitrary trees (so it can be like, main branch with 5 children-siblings but also a chain of 5 consecutive branches).

(gt stack submit > pushes everything in the current "stack" and creates PRs if they don't exist already)

traverse pushes the branches (with force-with-lease if needed). PRs are handled separately via git machete github create-pr.

---

Thanks for posting and lmk what you think ‼️

[ForsakenHarmony]

Would love to have the traverse integrated into the IntelliJ plugin, having to call a separate command for managing PRs seems like a step down from graphite

haven't checked how exactly the check for merged PRs in graphite works, may just be checking if the remote branch is gone (maybe confirms with the GitHub API)

[PawelLipski]

Would love to have the traverse integrated into the IntelliJ plugin

In progress as you see :)

having to call a separate command for managing PRs seems like a step down from graphite

Know what? lemme open an issue for having PR management also integrated into git machete traverse: https://github.com/VirtusLab/git-machete/issues/700

[zmerr]

Would love to have the traverse integrated into the IntelliJ plugin

In progress as you see :)

Catching up on that this week.

[PawelLipski]

Catching up on that this week.

<3

[mkondratek]

Hi Ina 👋 I ve talked with Paweł about the #1213 and #1235.

The conclusions:

1. Rebase on Remote is something that was not planned in the scope of the traverse feature.
2. Rebase on Remote is not required for a basic traverse - we treat CLI traverse as a reference.
3. Rebase on Remote can be considered later and is not a blocker for the traverse feature.

So if you are still interested in finalizing things (we will appreciate that!) please focus on the traverse feature. We aim to have it working like the CLI traverse (no rebase on remote needed at this point).

Once you finish the traverse feature we can discuss the Rebase on Remote (and its cases - diverged from & older/newer).

---

@PawelLipski, please confirm that these are our findings/decisions ✅

@zmerr, thank you, and please confirm that you are ok with that 🙂

---

Also in the scope of the project-related topics, I think the most convenient way is to discuss them within issue comments so no information/decision/finding gets lost (that's a note esp. for me as I was the one who started talking things through on Slack 😆)

[PawelLipski]

+1, signing with both hands ✍🏻✍🏻

[zmerr]

Hi Mikolaj👋 Thanks for sharing all of that, here. So for now, I will be focusing on Traverse ✅

[mkondratek]

I ve linked the other related PRs ☝️ the changes are mostly refactors and code improvements that were worth to be applied before

[mkondratek]

@PawelLipski in the scope of the action icon.

My thinking: Nothing easy comes to my mind that could illustrate the traverse. Happens, in this case we could use a letter T (like "Traverse"), probably within a circle to make it look better. Smth like ©/©.

WDYT?

[zmerr]

Just suddenly:

https://images.app.goo.gl/xSypNikcWvpWwCUe9

[mkondratek]

Just suddenly:

https://images.app.goo.gl/xSypNikcWvpWwCUe9

too close to the refresh action 😢

But I am open to more suggestions of yours too ofc!

[zmerr]

T looks the nicest then 👌

[mkondratek]

And the other thing - the diverged branch resolving.

Currently, during traverse we can sync a branch by rebase and then reset to remote by sync-to-remote - this leads to red edge again. In some cases start->sync-to-parent (rebase)-> sync-to-remote (reset) can give finally the very same situation that we stared from.

We can:

1. Allow the user to do that 🟢 - stupid but it's usage not a tool
2. Do not offer reset to remote - this is how CLI works - it is consistent then
3. your ideas???

I am obsessed about the consistency so 2 wins for me 🤣

[PawelLipski]

2. Do not offer reset to remote - this is how CLI works - it is consistent then

Definitely. Let's be opinionated.

Also... shouldn't reset to remote be only offered in case the local branch is older then the remote branch? which doesn't include the case of a freshly-rebased local branch. That's exactly how CLI "knows" that after a rebase, reset to remote shouldn't be suggested (force-push should be suggested instead).

[PawelLipski]

Also... shouldn't reset to remote be only offered in case the local branch is older then the remote branch?

Remind me... how does it look like currently? for diverged with remote case, there's always a dialog displayed with both options (push-force; reset to remote) displayed? 🤔

[PawelLipski]

But I am open to more suggestions of yours too ofc!

Hmmm given the meaning of traverse:

I considered something along the lines of one of:

• 🐾 / 👣
• 🚶🏻
• 🚜 (see https://github.com/VirtusLab/git-machete#git-machete -> paragraph right before the animated gif)
• 🚗
• ....

T also feels okay... WDYT folks?

[mkondratek]

Also... shouldn't reset to remote be only offered in case the local branch is older then the remote branch?

Remind me... how does it look like currently? for diverged with remote case, there's always a dialog displayed with both options (push-force; reset to remote) displayed? 🤔

yes