Re: Bug: git restore --staged --worktree not working in git version 2.26.2.windows.1

From: Eric Sunshine <sunshine@sunshineco.com>
Date: May 1, 2020, 08:42 UTC
Message-ID: <CAPig+cTqqHqM6i8JHTLoY8SyCu=WWh1KCH2HCj8VNNxvux-toQ@mail.gmail.com>
In-Reply-To: <AM6PR09MB298072F9FEB469130EAEB8F18BAC0@AM6PR09MB2980.eurprd09.prod.outlook.com>

On Tue, Apr 28, 2020 at 5:16 AM Harri Mehtälä <harri.mehtala@finago.com> wrote:

Show 13 quoted lines

> I am trying to do git restore --staged --worktree for a file. I
> understood from the documentation that you can do both.
>
> "Specify the restore location. If neither option is specified, by
> default the working tree is restored. Specifying --staged will only
> restore the index. Specifying both restores both."
>
> $ git restore --staged --worktree pom.xml
> $ git status
> Changes to be committed:
>     modified:  pom.xml
>
> It looks like currently I have to do both separately.

If you read a bit further in the documentation, it says that you must specify --source when combining --staged and --worktree, so your "git restore" invocation is incorrect. Unfortunately, "git restore" is a bit buggy in this regard since it blindly accepts this invalid combination of options when it should instead error out. I submitted a patch series[1] which fixes this shortcoming.

Having to specify --source in this case can be cumbersome if you just want to restore from HEAD (a reasonable default), so the submitted patch series[1] also makes --source default to HEAD when --staged and --worktree are combined.

[1]: https://lore.kernel.org/git/20200501082746.23943-1-sunshine@sunshineco.com/T/