Rebase "onto" line in the interactive rebase UI is sometimes duplicated in the commits to rebase

[Mumeii]

Hi

I encounter a strange behhavior with the new rebase window.

I'd like to know :

• If it's either a bug or a normal behavior.
• And if it's a normal behavior, what it mean ?

---

OS : Mac OS Catalina v10.15.7
VSCode version : 1.51.1
Gitlens version : 11.0.4

---

I want to rebase the following set of commits over themself :

* c9c925f (HEAD -> tech/CI-enhancement, origin/tech/CI-enhancement) fixup! tech: remove install step & dockerize tests
* 4de658e tech: remove install step & dockerize tests
* 22a9d09 tech: Jest & jest-html-reporter version update To prepare a subsequent NodeJS version upgrade
* 89f3f0a tech: turn jest testResultsProcessor into reporter Doing so in order to ...
* 1cbc2f3 tech: ignore node_modules* : easy version swapping
* 525325a tech: major enhancement to Dockerfile
* d80fada tech: define NODE_ICU_DATA only when necessary
* a1cb5aa tech: remove old useless Jenkinsfile-open & -close
* dc9d67b tech: remove useless comments
* 78bdbd2 tech: add .dockerignore
* 1bc9ae0 tech: add timestamps to CI log lines
* 070ee0a fixup! tech: use stages for docker builds
* c4f4a61 fixup! tech: use stages for docker builds
* f213b58 tech: use stages for docker builds
* 0889eb9 fixup! tech: prevent chromium download for tests
* 99ff719 tech: prevent chromium download for tests

To do so, I perform a git rebase -i HEAD~16, as I usualy do

I was expecting to have 16 lines displayed, like the command line version of git rebase usually do.

Instead of that, I got the following display.

Notice :

• the extra line at the end which seems to be a duplicate of the first one, but without any SHA1 associated
• I have --autosquash activated by default on rebase, and that there is fixup!entries in the commits I intend to rebase

What mean this extra final line been displayed ?

Thanks you for your feedback about it, and more importently, for Gitlens which is a great tool !

[lupalby]

I was about to open an issue myself about the same thing. I think it's a bug, I do not understand what kind of feature would that be. In my case, the last line does show an SHA1, that is the same as the commit that it shares the message with. I have done a few rebases in the last week, and usually the duplicated line is the same as the first line, but today it was the same as the second line. Even stranger!

In general I don't mind the new rebase window, I find it more user-friendly especially for some of my colleagues that aren't as well-versed in git, but this creates some confusion.

[lupalby]

Actually by looking at my screenshot I just realized that the title of the rebase is also incorrect: "Rebasing 9 commits onto b733e3a3" is wrong, as that is clearly the second to last commit in my local branch. Perhaps that last line is supposed to show which commit we are rebasing onto, to help giving an idea in which direction is the timeline (up or down), but since it picks the wrong commit as base it looks like a duplicate

[eamodio]

Yeah, the last line it to provide extra context for the rebase -- the commit the rebase will be sitting on top of.

@lupalby Do you still see the wrong commit showing for the last line in the latest version (11.0.6)?

[lupalby]

I just tried again, I still see the same behavior even with version 11.0.6. I reloaded the window too, just to make sure it was using the latest version after the update. The "context" commit should not be any of those that are being rebased.

[eamodio]

@lupalby what does your rebase command look like that causes that output? I never see the "base" commit in the rebase list.

[lupalby]

Nothing fancy really. I am in branch am/os1 and I simply ran git rebase -i origin/master
Let me know how else I can help debug this

[lupalby]

And let me clarify. The rebase list is perfectly correct. The "base" commit is the wrong one, as I expect it to be the newest commit from master, that I am rebasing on top of, rather than one of the commits of my branch

[lupalby]

@eamodio After some more digging I think the issue does not originate in your extension, but from Git. It is something to be aware of though, because if it is somehow a "normal" behavior of Git, it can invalidate the way you obtain info about the "base" commit.
Below you can see the rebase-todo both in VSC and using a plain notepad to show the raw text:

You can see that your interactive rebase UI shows just what is provided by the raw text. I am not quite sure why Git says Rebase d8f36471..457c562a onto aea5061b
d8f36471 is the newest commit in origin/master, and 457c562a is the latest commit I added in my branch. I am not 100% sure, but it could be that aea5061b was the first commit that I added into my branch when I started it, and it is not anymore the first one in there because I shuffled commits around during a previous interactive rebase, including some squash/fixups as well. If that is the case however, it happened weeks ago and I did other non interactive rebases in the meanwhile too, so I am surprised that it still remembers of that. If you move commits around and then try rebasing again afterwards, do you see a similar behavior?

[eamodio]

Does anyone know why the onto on the line: # Rebase d8f36471..457c562a onto aea5061b (7 commands) above is also contained in the set of commits to be rebased? That seems completely wrong to me.

/cc @derrickstolee?

[derrickstolee]

Cc: @dscho who knows a lot about this area.

[dscho]

Hmm. The aea5061b commit really is supposed to be the one you rebase onto. I.e. if you truly call git rebase -i origin/master, I would be highly surprised if the interactive rebase showed anything but the shortened commit hash of origin/master after that onto.

Further, the revision range before that is generated here, and it only shows a different base than <onto> if a differing <upstream> was provided, i.e. something like git rebase -i --onto <onto> <upstream> (the corresponding code would be here).

There is an exception to that rule: if you provide neither <onto> nor <upstream>, Git tries to figure out where you forked off of the remote-tracking branch that is configured as the "upstream" branch. From the docs:

If is not specified, the upstream configured in branch..remote and branch..merge options will be used (see git-config[1] for details) and the --fork-point option is assumed.

Details about the way the fork point is determined are found here:

Use reflog to find a better common ancestor between <upstream> and <branch> when calculating which commits have been introduced by <branch>.

When --fork-point is active, fork_point will be used instead of <upstream> to calculate the set of commits to rebase, where fork_point is the result of git merge-base --fork-point <upstream> <branch> command (see git-merge-base). If fork_point ends up being empty, the <upstream> will be used as a fallback.

And crucially:

If your branch was based on <upstream> but <upstream> was rewound and your branch contains commits which were dropped, this option can be used with --keep-base in order to drop those commits from your branch.

I think that might have happened here: the upstream might have been rewound at some stage.

[eamodio]

@derrickstolee thank for the cc 😄

@dscho Thank you for the write up. So, if I'm understanding it correctly, while GitLens should be able to rely on that onto value there are cases where it could end up being confusing to users. So maybe I should just hide the "onto" row, if the "onto" sha is in the list of sha to be rebased.

Does that make sense?

[lupalby]

@dscho that is very insightful, thanks for sharing.
Just to clear the water, in all this I was always the only one pushing to Github, so there is no way that remote may have had changes that did not come from my local. I am sure I have never used onto or anything like that. I have originally created the branch off of master, then at a certain point I wanted to use some feature from a development branch before it was merged into master, so I rebased am/os1 (my branch) on that branch with git rebase -i origin/dev-branch and once dev-branch got merged into master I rebased on master with git rebase -i origin/master. During one of the rebase operations I have also moved commits around and squashed some of them, and the commit that was originally the first one of my branch (aea5061b) ended up somewhere in the middle.
Could it be that combining rebase on a different branch with shuffling commits may have caused this mess? Since I never specified onto, it looks like git had to figure some stuff out by itself and something may have gone wrong.

If it is of any help, I am more than happy to test anything for any of you. I truly appreciate everybody's work and this is the least I can do to give back.