Re: git switch/restore, still experimental?

Ævar Arnfjörð Bjarmason [off-list ref] writes:

On Wed, May 05 2021, Sergey Organov wrote:

quoted

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

On Tue, May 04 2021, Elijah Newren wrote:

quoted

On Tue, May 4, 2021 at 3:36 AM Gábor Farkas [off-list ref] wrote:

quoted

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.

[...]

quoted

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