"git rebase -p no longer supported" but needed

[Philipp]

Dear git devs,

I really hope I am not wasting your time with an easily fixable problem, but I'm really out of luck here.

I was working with Visual Studio 2022 and had a local commit. I made a change on another computer and pushed it to the remote branch. Then I tried to merge them together. This started a rebase process, which is stuck now.

This is just for context, the reason I'm reaching out for help here is this:

The way out of my situation seems to be using "git rebase --continue" but it always says the command isn't supported. However I can't seem to find any information regarding this limitation.

I reinstalled Git for Windows multiple times and restarted my computer. I always used the default settings in the installation process to avoid any errors.

There must be something really obvious I'm missing and I hope someone finds the time to help me out here.

Thank you very much in advance and kind regards,

Philipp

[Philip Oakley]

Some thoughts on extra info that may help.

What version are you on?

What are your config setting for the merge? - did you explicitly merge, or was it a pull (with rebase settings)?

do have the exact command used (from history)?

What does the git log say - does it think you are done, but git is confused, or does it still think you are at the previous commit with the one pick commit still to be finalised?

[Philipp]

Thank you for the fast response and help!

I'm on the newest Git for Windows version: 2.35.1.windows.2

This is the git status I ran into initially after the rebase got stuck (my original mail mentions branch 0.5.5 where I tried to "rescue" the branch and just start new without the changes).

More context for the situation:

I pulled and had to resolve a conflict. I chose the changes of the local branch b375a432.

Then I merged (pressed the Visual Studio "run merge"-button) and git got stuck in the rebasing.

The settings for rebasing on pull are not defined it seems. But since it did a rebase I think it used a pull with rebase.

Really the most important question is why it would say "rebase -p is no longer supported" after suggesting I run the command.

It doesn't give my any other context as to why I can't use this command to get out of this situation.

I can't run any rebase command in general.

[Philip Oakley]

The error message comes from https://github.com/git-for-windows/git/blame/main/builtin/rebase.c#L1158 and is fairly recent from https://github.com/git-for-windows/git/commit/a74b35081c51adbde3ef01870ba03e859db33be6

The implied `-p` option is for the now unsupported ` --preserve-merges` option of old.

If you are using a graphic UI then the option may have been added without you appreciating it, or it being part of one of your (or the UI's) configs - You indicated you were using the Visual Studio integration... Maybe the problem is there?

Have you looked at the man page https://git-scm.com/docs/git-rebase to try some alternate commands to finish the rebase (e.g. --quit, etc)

use `git help --config` to see what all the configs available are, and ` git config --list --show-origin` to see where all your configs come from and their key=value pairings

Do use the `gitk` viewer to allow investigation of the current 'state' of your repo and the stalled rebase, so you can use the sha1 values to recover any work that doesn't end up on a branch in the right expected place (it's not lost, just sitting idle in the object store) when you quit/abort/etc.

If it is a repeating fault, consider reporting it.

[Konstantin Khomoutov]

On Wed, Feb 16, 2022 at 11:51:43PM -0800, Philipp wrote:

[...]

> I'm on the newest Git for Windows version: 2.35.1.windows.2

[...]

> Really the most important question is why it would say "rebase -p is no
> longer supported" after suggesting I run the command.
> It doesn't give my any other context as to why I can't use this command to
> get out of this situation.
> I can't run any rebase command in general.

You might have an alias lingering or some other intervening installation of
Git files from which get used for whatever reason.

Let's try to debug further.

First, run

git config --list --show-origin

and see whether you have any entries named like "alias.rebase" or something
else looking fishy.

Second, try to

echo $PATH

to see where the binaries to run are looked up at.

Third, run

which git-rebase

to see what your shell thinks the git-rebase program is available as.

Fourth, try running your normal rebasing while having

set GIT_TRACE=1

executed in the shell before the action - this will make Git extra chatty
about what it calls to carry out its various tasks.


And while we're at it, please refrain from posting images of texts: its too
inconvenient for users who use text-mode mail readers, like I do, and it's
completely useless anyway: you could just copy the text from your console and
paste it into your mail message anyway.

[Philipp]

Thanks again for the responses!

I was wondering if you could see the images. The option was there so I used it, but I will post the text from now on.

git config --list --show-origin:

• no "alias.rebase" setting anywhere
• pull.rebase=false
• rebase.autostash=false

These two are the only rebase related settings in the config files.

echo $PATH:

It's very hard to read any helpful information from this because of the formatting.

Would I get the same information if I just look up the path variables in the Windows settings?

Or am I mixing something up here?

$ which git-rebase
which: no git-rebase in (...long list of paths...)

$ which git
/mingw64/bin/git

So have I set my path variables wrong then?

My path variable (in Windows settings) for MINGW64 does point to a non existent folder at least.

So I will try fixing the path and then try again.

But still, why would git recognize its path for MINGW64 and not git-rebase?

And why did the older version also not have a problem with this?

I can't run the git rebase command again to try debugging the command as I finished rebasing with the older version.

[Konstantin Khomoutov]

On Fri, Feb 18, 2022 at 01:27:57AM -0800, Philipp wrote:

> Thanks again for the responses!
> I was wondering if you could see the images. The option was there so I used
> it, but I will post the text from now on.

I could, and did, actually, but it wasn't not too convenient ;-)
I mean, this is a technical mailing list, and when reading their traffic I
expect that 99.9% mails are plain text and it's OK to use familiar tooling.
Well, actually it's not just my personal convenience; you can read a good
summary of "the whys" over there at [1].

> git config --list --show-origin:
>
> - no "alias.rebase" setting anywhere
> - pull.rebase=false
> - rebase.autostash=false

>
> These two are the only rebase related settings in the config files.

Good!

> echo $PATH:
> It's very hard to read any helpful information from this because of the
> formatting.

Well, it's just a list of paths delimited either by ':' or ';' - depending
on how Git Bash shows them; I'd expect to see ':' there.

> Would I get the same information if I just look up the path variables in
> the Windows settings?

No.
Well, technically yes, but the thing is, there are per-system settings and
per-user settings; the latter override the former, and seeing them right in
the shell shows the "actual" value which is definitely used to look up
programs called by their short name such as "git.exe" or just "git".

> Or am I mixing something up here?
>
> $ which git-rebase
> which: no git-rebase in (...long list of paths...)

Good!

> $ which git
> /mingw64/bin/git

This one looks odd.
Well, maybe Philip Oakley could verify this for us? - I don't have a Windows
machine in my vicinity at the moment.

> So have I set my path variables wrong then?
> My path variable (in Windows settings) for MINGW64 does point to a non
> existent folder at least.
> So I will try fixing the path and then try again.
> But still, why would git recognize its path for MINGW64 and not git-rebase?
> And why did the older version also not have a problem with this?

Well, two things:

* It's OK that you do not have git-rebase (with the dash in its name).
I just wanted to make sure you do not have it.

The reason is that Git has a special logic which makes its "front-end"
or "entry-point" executable, "git.exe", look up "git-whatever" if
the user called "git whatever". This allows to easily install external
commands for Git. For instance, I have "git-whenmerged" installed.

* As to the pas to the front-end executable, I'm not sure.
To me, it looks strange, but I don't have a Windows machine handy,
so would like to hear what others do.

> I can't run the git rebase command again to try debugging the command as I
> finished rebasing with the older version.

This, in itself, is not a problem: you can create an empty repository, record
two or three commits updating a dummy file and then rebase some of them.
That is, you don't need to mess with a "real" repository which contain
precious data.

1. https://meta.stackoverflow.com/a/285557

[Philip Oakley]

> this is a technical mailing list, and when reading their traffic I

expect that 99.9% mails are plain text

Unfortunately this particular list is a googlegroup so they offer all the fancy stuff ;-)

> maybe Philip Oakley could verify this for us? - I don't have a Windows
machine in my vicinity at the moment.

I get the same on Win10-Home (21H1, bld 19043.1526)

```

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (brshow)
$ which git
/mingw64/bin/git

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (brshow)
$ git version
git version 2.35.1.windows.2
```

Title bar " MINGW64:/c/git-sdk-64/usr/src/git"

So an exact match for the git path. with root set at:

```

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (brshow)
$ cd /

phili@Philip-Win10 MINGW64 /
$ pwd -W
C:/Program Files/Git

```

> you can create an empty repository, record two or three commits updating a dummy file and then rebase some of them.

definitely worth trying to recreate the problem.

I strongly suspect that it is an interaction with the Visual Studio integration and the "(pressed the Visual Studio "run merge"-button)" [Phillip's message of 17/02/2022, 07:51 my time].

You may also need to create a local clone with a recreated conflict to re-enact the "pull" (if it's a dummy repo, and you have access, create one on GitHub for easy sharing). Having a solid MVCE makes all the difference.

I do have VS 2019 community ed locally, but don't use it's Git integration!

I haven't looked at the code for "git rebase --continue" to see how it could reach that "rebase -p is no longer supported" report (lots of twists and turns no doubt) !

[Philip Oakley]

Extra check: look in the `.git/rebase-merge/' directory (is it present?) and see if there is a further directory `rewritten`?

the code at L1154-1158 (ends with that "die" message) checks for the existence of that directory to determine that somehow you were in a '--preserve-merges` command.

Note that in line L1179-1180 there is a check for commands given on the command line that dies differently.

Lines relative to my C:\git-sdk-64\usr\src\git\builtin\rebase.c

If you can check if that `.git/rebase-merge/rewritten/' still exists, then that would be great. 

We then just need to work out why it's there!

[Philipp]

Thanks again for the hints!

First:

I found the ".git/rebase-merge/rewritten" directory in a backup folder of my VS repo where the rebase problem was ongoing.

Second:

Realised just now that I forgot important information initially (was stuck on the error for two hours and focused on the latest error state).

1. Older Git for Windows version active (dont know which, sadly)
   1. starting rebase
   2. rebase gets stuck
   3. run rebase --continue and get error regarding my editor
      
2. Reinstall Git for Windows with newest version and default settings (2.35.1 windows 2)
   1. ".git/rebase-merge/rewritten" directory  exists
      
   2. run rebase --continue and get error I described in this post
3. Reinstall Git for Windows with version 2.23.0 and default settings
   1. run rebase --continue successfully
4. Reinstall Git for Windows with newest version again
   1. ".git/rebase-merge/rewritten" directory  doesn't exist

It's stupid that I didn't mention this right away, as this first part must the main origin of the problem then.

Aside from reinstalling Git for Windows I didn't change the .git folder in any way.

So my best guess is that the directory got deleted after the successful rebasing?

[Philip Oakley]

Hi Phillip,

Thanks for that clarification. It makes sense. The indicative directory will have been deleted once the rebase had been completed using the old/downgraded version (it was started with the old version..).

Can you check what your "pull" settings are?

In the command line use `  git config  --show-origin  --show-scope --get-regexp 'pull.*'  `.

In particular you are looking for lines ending `pull.rebase preserve`, which could have been set via the Visual Studio 'Git Settings' interface.

The setting will make a pull do both a fetch and a rebase, rather than a fetch and a merge, which probably wasn't what you wanted (maybe it was?)

If it is set then an upgraded Git will still either error out or die in various places when it sees that config option, without starting the rebase, but still a hassle, so the config settings will need readjustment.

I've reported the settings issue to Microsoft Visual Studio - hopefully they will realise what the issue is.

I'm also preparing a Pull request for Git-for-Windows to improve the error message should others get into the same situation as they upgrade after some hickup.

Thanks for sticking with the reporting.

Philip

[Philip Oakley]

My Pull Request for Git-for-Windows https://github.com/git-for-windows/git/pull/3708 has been accepted and merged.

The PR has also been submitted to the main Git upstream via https://github.com/gitgitgadget/git/pull/1155.

Comments welcome there.

[Philipp]

Hey Philip,

the command doesn't return anything and if I look through my config manually I can't find it either.

So it doesn't seem to be set.

Thank you very much for the help!