Re: git switch/restore, still experimental?

From: Sergey Organov <sorganov@gmail.com>
Date: May 6, 2021, 14:29 UTC
Message-ID: <87o8doue98.fsf@osv.gnss.ru>
In-Reply-To: <87mtt8uqec.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 60 quoted lines

> On Wed, May 05 2021, Sergey Organov wrote:
>
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>>> On Tue, May 04 2021, Elijah Newren wrote:
>>>
>>>> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:
>>>>>
>>>>> hi,
>>>>>
>>>>> the "git switch" and "git restore" commands were released two years
>>>>> ago, but the manpage still says "THIS COMMAND IS EXPERIMENTAL. THE
>>>>> BEHAVIOR MAY CHANGE.".
>>>>>
>>>>> i'd love to use them, but this warning gives me pause, perhaps i
>>>>> should wait until it stops being experimental, i worry that it might
>>>>> change in behavior unexpectedly and cause problems for me.
>>>>>
>>>>> considering that they were released two years ago, could the
>>>>> experimental-warning be removed now?
>>>>>
>>>>> thanks,
>>>>> gabor
>>>>
>>>> This probably makes sense.  The author of switch and restore isn't
>>>> involved in the git project anymore.  He decided to work on other
>>>> things, which was and is a big loss for us.  I think others (myself
>>>> included) didn't know all the things that might have been in Duy's
>>>> head that he wanted to verify were working well before marking this as
>>>> good, but these two commands have generally been very well received
>>>> and it has been a few years.  Personally, I'm not aware of anything
>>>> that we'd need or want to change with these commands.
>>>
>>> I am.
>>>
>>
>> [...]
>>
>>> And:
>>>
>>>    # Moves a branch (or -M for --force)
>>>    git branch -m old new
>>>
>>> That last one we can't have either because "switch" squats on "-m" for
>>> "--merge", which I daresay is a much more obscure use-case not deserving
>>> of a short option than "rename and switch to".
>>
>> Isn't --merge a different (and inferior) way to achieve what we already
>> have elsewhere with --autostash? Does it make sense to get rid of --merge
>> here in favor of --autostash?
>
> Probably, I haven't used the --merge option ever I think. Switching with
> dirty worktrees isn't really how I work.
>
> But to the extent that I've ever tried / run into errors with that I'd
> think that an option like --merge or --autostash is mostly a result of
> us being overzealous about "is_dirty() && die()" checks. E.g. rebase (at
> least a while ago, still) would refuse to rebase with a dirty tree, even
> though the path in question had nothing to do with paths that would be
> touched by the rebase.

Unfortunately, this will never solve the problem entirely. Global autostash mode probably will, more chances if stash will save/restore exact state of everything when applied to the original base.

>
> I suspect that much of the need for these sorts of options would go away
> with those checks being smarter, but it's separate from the "should we
> squat on -m" discussion...

It is not entirely separate. If --merge goes away, there will be no "squat on -m" anymore.

Personally, I'd just turn on global autostash mode if it were available, and forget about both --merge and --autostash, for the better.

Thanks, -- Sergey Organov