Interactive rebase order is backwards

[mbarak]

Issue Type: Bug

in the terminal:

export EDITOR="code -w"
git rebase -i master

Extension version: 11.0.1
VS Code version: Code 1.51.1 (e5a624b788d92b8d34d1392e4c4d9789406efe8f, 2020-11-11T01:11:34.018Z)
OS version: Darwin x64 19.6.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2600)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	3, 3, 2
Memory (System)	32.00GB (3.85GB free)
Process Argv	--crash-reporter-id 4691b649-08b6-4699-93cc-24b45479e024
Screen Reader	no
VM	0%

The order of commits in the gitlens interactive rebase editor is backwards.

In regular git on the terminal, the commits are ordered in the order they will be applied.
Top commit will be applied first, then the next, etc.

In gitlens this is backwards.

[eamodio]

This is by-design, but I would like to add an option to have it either way

[grncdr]

I would really love to see this option. I like the look and interaction model of the interactive rebase editor, but the reversed order (compared to what I'm used to) throws me off every time it opens.

Is the reasoning of the current design so that rebasing more feels more like re-ordering "git log"? That makes some sense, and I think I would get used to it, but then it should show the current HEAD commit (the grey row) at the top instead of the bottom.

I don't see much value in showing the current HEAD commit at all, since it's not editable, and just duplicates information already in editable row at the top.

[evocateur]

The default sort of git rebase -i isn't being respected currently, which is not at all valuable, imho (violating a literal decade of muscle memory). The defaults should match, with an option to mangle it into git log-order. First thing I did when stumbling over the new UI was look for a way to restore the correct sort, was very disappointed to find it missing.

[jimlloyd]

For what it's worth, having the commits displayed in reverse order makes this feature unusable for me, so I simply disable it. But it looks like a cool feature that I would use if the commits were displayed in the correct order.

[eamodio]

Yeah, I hear everyone on this -- I want to get this in as well, it's just all about finding the time. I'd be VERY open to a PR for it 😄

[distante]

+1

it is hard to switch when the order is exactly the reverse of what we know for years.

[yeroc]

@eamodio Are you open to a PR that simply reverses the order or are you looking for something more sophisticated that supports both ways of ordering the entries?

[eamodio]

Definitely looking to support both modes -- and ideally hot-swappable (but at a minimum via a setting). I was thinking about just having a flag to the webview about the ordering which would set some css class (to handle all the changes required to show the correct indicator lines).

[fsackur]

Contrasting perspective - I prefer the descending order

[johnmcase]

Any updates on this? I like the idea of the web editor but agree that it is very confusing that it is backwards from how the traditional text editor works.

[jkwuc89]

+1

I would also like to see an option to change the commit order.

[ghost]

Fix up looks broken with this arrangement... please 🙏🏻 add an option to put it in the CORRECT order.

[lgarron]

Just chiming here that this is super jarring to me. I've been trying to give the interactive editor a real shot since it started popping up for me, but I'm permanently turning it off because it's inconsistent with the order git uses.

[chadly]

I think this should be fixed too as an option to reverse the order the same as the text editor does. It is jarring for someone coming from using the text editor to edit rebases.

That being said, this feature makes the interactive rebase much more accessible to people who may not have used it before. With that context in mind, it makes total sense in my mind to mirror the log/history view as a way to be more beginner-friendly.

Plus, after a few days, I've gotten used to it.

Kudos to the team for building a cool feature that even "text-editor people" want to use!

[eamodio]

Thanks for all the feedback. I will be actively working on this for the next release, and will hopefully have something "soon" for people to play with in the GitLens Insiders version.

[eamodio]

Thanks to @d13, our newest (first, other than me) GitLens maintainer, we've landed this awesome toggle on the rebase editor:

It is also controlled by the new gitlens.rebaseEditor.ordering setting.

Can you please play with this in tomorrow's GitLens insiders edition?

You can install the GitLens insiders edition from here.

Please be sure to disable or uninstall the stable version of GitLens first.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.