Re: [PATCH] restore: allow --staged on unborn branch

From: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
Date: Feb 7, 2024, 16:39 UTC
Message-ID: <CYYZUAGA7I6C.2M4CHKN00W3P4@gmail.com>
In-Reply-To: <xmqqle7wcl7h.fsf@gitster.g>

On Wed Feb 7, 2024 at 9:36 PM IST, Junio C Hamano wrote:

Show 11 quoted lines

> Ghanshyam Thakkar <shyamthakkar001@gmail.com> writes:
>
> > Some users expect that being on an unborn branch is similar to having an
> > empty tree checked out. However, when running "git restore --staged ."
> > on unborn branch having staged changes, the follwing error gets printed,
> >
> >     fatal: could not resolve HEAD
>
> Sounds like a sensible behaviour---there is no HEAD so there is
> nothing to resolve.  With "git resetore --staged ." in such a state,
> what did the user try to do?  "git reset" (no other arguments)?

Yeah, I did "git reset" (I am that user btw). But I suppose this is a case of UX. If a user is using "git restore --staged ." every time they want to unstage something, then why would they expect it to fail on an unborn branch when something similar (e.g "git reset") does not?

Also that HEAD, I suppose, is our assumption of the user's intent. And intent of the user using "git restore --staged ." on unborn branch is to unstage the changes relative to empty tree. Besides "git reset" already does this so the matter of assuming empty tree on unborn, I suppose, would already be settled. Therefore, wouldn't assuming empty tree on unborn when also using "git restore --staged ." be reasonable and consistent?