Make the wording of rebase less scary

[danielo515]

Hello.
Thank you for this great, great tool. Thanks to it I can use Nvim without missing VSCode UI at all.

Something I find particularly scary is the wording of rebase. The way (I think, correct me if I'm wrong) that you rebase your current branch on top of another one is by going to the local-branches section, put the selector on the branch you want to rebase (lets say it's master), and then hit r.
Then a confirmation modal (which is always wonderful) appears and asks for confirmation, but it says: Are you sure that you want to rebase "your-branch" into "master"
As far as I know, this rebases master with your changes from your-branch and keeps master untouched, all is done in your current branch. However, the wording ins confusing and may feel like you are going to modify the "master" branch, which is not what you want.

I understand that the message follows the GIT conventions, which I always found confusing about all the things related to rebasing. Will it be possible to make lazygit more friendly in that way?

[mark2185]

Which changes do you propose? I took a look into the message and it actually says "are you sure you want to rebase X ONTO Y", which was my first suggestion, which is much clearer than into.

I think the semantics is quite clear, you are changing the base (rebase) of your-branch (whatever it was) to master.

[mark2185]

Are you sure you want to rebase "your-branch" onto "master"?
vs
Are you sure you want to rebase "your-branch" on top of "master"?

I'm not sure if it's any clearer. Because you can rebase onto a commit, and on top of would suggest that there's an option to rebase below a commit as well?

Also, it can even include a little explanation, because, IMO, this is one of the first more advanced git commands that someone that is yet a beginner but starts to use more advanced git features will use.

Maybe we could add some sort of git tutorial mode for people new to git in general.

Until then, my advice would be not to use anything through lazygit that you haven't done manually before. E.g. rebase, hard reset, stash, deleting commits etc.
Think of lazygit (or any other git client for that matter) as a tool to help you do things you already know how to do, but with fewer keystrokes.

[danielo515]

I do rebase on a regular basis, and still found the wording scary. It may be because all I do is go to my branch, then rebase, so I know I am working on my branch. Lazy git makes me select the other branch first, then rebase, and that is probably what confused me.
Good advise anyway.

[mark2185]

Well, I guess we could add the command we're gonna run under the hood in such situations. Should help with potentially dangerous operations.

Something like

Are you sure you want to rebase "your-branch" on top of "master"?

This entails:
$> git rebase --interactive "master"

Think of it as "log first, run second".

@jesseduffield a penny for your thoughts :)

[jesseduffield]

'on top of' and 'onto' are used interchangeably in the git docs (see here and here), so I'm not averse to changing the language from 'onto' to 'on top of' if we think it's clearer to a newbie. But I do wonder if there are people who are so familiar with the 'onto' wording that they'd get confused by seeing the 'on top of' wording.

I say we run a poll to see which wording is better. I've just posted one to my twitter (which I have never done before but we'll see if it gets any traction).

As for the idea about showing what command is going to be run, I'm interested in having something like that, but I would want to to roll that out to pretty much all commands instead of just one (and I suspect it would take some refactoring to get a hold of the command to run before the user actually confirms to run it)

One thing I'll say is that I do want lazygit to be newbie friendly, and I'm happy for it to be a little noisier if it means we're explaining to the user what commands do. Though many git commands need a page or two of documentation for you to understand what's actually going on, so I'd rather link to documentation than try to explain everything within the app. Whether that would be our own documentation or git's own, I'm not sure. Definitely needs more thought.

[jesseduffield]

Let it be known: people prefer 'on top of'