History partial completion with Up key isn't implemented in git-bash

[AntonioRedondo]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

git version 2.25.1.windows.1
cpu: x86_64
built from commit: cceb69da75b4906bb04cfb3a2f7f37b12b985ec3

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Microsoft Windows [Version 10.0.18363.1256]

• What options did you set as part of the installation? Or did you choose the
  defaults?

Defaults

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Nope

Details

Git-bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

For example, on bash on Linux, if in the terminal is written

npm

and I press the key ↑, the history only will iterate over entries that start by npm:

npm i
npm list
npm view

However, on Windows using Git-Bash, what it's already written on the terminal will be ignored and when pressing ↑ history will iterate over all entries in reverse chronological order.

npm i
git status
ls -la
npm list

• What did you expect to occur after running these commands?

If I press ↑ when npm is already typed on the terminal:

npm i
npm list
npm view

• What actually happened instead?

What is written in the terminal is ignored and history will iterate over all entries in reverse chronological order

npm i
git status
ls -la
npm list

[landstander668]

The behaviour you're describing (iterating through all commands sequentially) has been the default on every Linux distribution I've tried, spanning many years. My guess would be that your normal environment has something similar to the following configured, in either ~/.inputrc or /etc/inputrc.

"\e[A": history-search-backward
"\e[B": history-search-forward

[landstander668]

Apparently it can also be implemented like this, in one of the various bash initialization files.

bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'

[AntonioRedondo]

OMG! I added the two commands you suggest to C:\Program Files\Git\etc\inputrc. And history partial completion now works! How come this isn't the default behaviour and the ↑ and ↓ keys aren't bound to these commands?

[landstander668]

My guess would be it's a backwards compatibility thing, where it was never made default simply because the feature didn't exist (at least in the Bash world) back in the early days and changing that might break the expectations of existing users. As for Git for Windows, I'm pretty sure it simply inherits the upstream defaults from MSYS2 in this area.

That being said I certainly find the feature helpful, and any potential disruption stemming from changing this behaviour seems like it would be quite minimal. So perhaps it's worth tweaking the default in this case.

@dscho, do you have an opinion on this? I'd be willing to put together a PR if you're comfortable with the idea.

[dscho]

I added the two commands you suggest to C:\Program Files\Git\etc\inputrc.

This will be overwritten the next time you re-install/upgrade/downgrade Git for Windows. It is not intended to be modified by the user. ~/.inputrc is the correct place, as @landstander668 suggested.

It is not my experience that this is the default in Linux. I am currently using Ubuntu 18.04 via WSL and do not recall being puzzled by the Cursor Up key doing what @AntonioRedondo wants it to do.

And quite honestly, if my reaction is any indication, I would be surprised if such a change would go without a ton of very vocal complaints. I know that my muscle memory would be disrupted by that change.

Maybe a checkbox in the installer (off by default) might be acceptable.

[AntonioRedondo]

This history partial completion feature doesn't stop users to use the not-fancy history not-partial completion mode since this is the behaviour when there is no text written in the terminal.

In order to request this feature I assumed (erroneously) 1) that this is the default for Bash, and 2) that this feature is always something good to have (to the point in my personal case that it's a must).

But given your insight and the risk involving this change I think it's a fair compromise to instead add a checkbox in the installer. Also, this could be complemented with documentation on the website, nothing extensive, just to mention somewhere that this behaviour can be changed with a couple of lines in a file.

[dscho]

This history partial completion feature doesn't stop users to use the not-fancy history not-partial completion mode since this is the behaviour when there is no text written in the terminal.

If you knew how often I search the history after typing a couple letters, you would not have said that.

I think it's a fair compromise to instead add a checkbox in the installer.

And I think it will make a very good first contribution from you.