git switch/restore, still experimental?

git switch/restore, still experimental?

[Gábor Farkas]

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

RE: git switch/restore, still experimental?

[Felipe Contreras]

Gábor Farkas wrote:
> 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.

It's precisely because the behavior may change that they are labeled as
experimental.

I have 15 of experience using git, and I have tried to use them but to
me they are too cumbersome.

For example I would expect this to work:

  git restore @~ -- file

But it doesn't, I need to specify `-s @~`.

git checkout is more user-friendly to me, so purpose of git restore is
defeated.

If the interface is changed, perhaps it will be useful to me. It isn't
at the moment.

Cheers.

-- 
Felipe Contreras

Re: git switch/restore, still experimental?

[Elijah Newren]

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.

That said, we're only a few weeks from -rc0, and I'd rather remove the
experimental label early in a release cycle, so maybe this would be a
good thing to do after the June git-2.32 release.  That'd give plenty
of time for others to chime in with anything they might be aware of
that they want or need fixed.

Thanks for flagging this.

Elijah

Re: git switch/restore, still experimental?

[Eric Sunshine]

On Tue, May 4, 2021 at 11:47 PM Elijah Newren <newren@gmail.com> wrote:
> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:
> > 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.".
> >
> > considering that they were released two years ago, could the
> > experimental-warning be removed now?
>
> 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.

As a point of interest, Duy introduced multiple worktree support
(which eventually became git-worktree) in late 2014, and it's still
marked as experimental in the documentation (though not in loud
uppercase).

Re: git switch/restore, still experimental?

[Ævar Arnfjörð Bjarmason]

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.

I think it's quite confusing that "git switch" doesn't switch to a new
"doesnotexist" branch on something like:

    git switch doesnotexist

But requires:

    git switch -c doesnotexist

I mean, I see why. You don't want a typo of "master" as "maaster" to
create a new "maaster" branch, so really that's out. But it really
should be:

    # -n or -N for --new / --new --force (the latter just in case of a
    # race, and just for consistency)
    git switch -n doesnotexist

The design choice of squatting on "-c" for "create" as opposed to "copy"
as implemented in 52d59cc6452 (branch: add a --copy (-c) option to go
with --move (-m), 2017-06-18) has the knock-on effect that we can't
mirror the "git branch" UI. I.e. to make "switch" be "branch with
checkout" for these common cases.

I.e.:

    # copies a branch and config from old->new (or -C for --force)
    git branch -c old new
    # just creates a "new" starting at "old", but no copying!
    git switch -c new old

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".

In summary, I think it should be changed to act like this:
    
    |---------------------------+------------------------+---------------------------|
    | What                      | Now                    | New                       |
    |---------------------------+------------------------+---------------------------|
    | Switch                    | git switch existing    | git switch existing       |
    | Error                     | git switch nonexisting | <no change (errors)>      |
    | Switch with --merge       | git switch -m branch   | git switch --merge branch |
    | Create                    | git switch -c new      | git switch -n new         |
    | Create from existing      | N/A                    | git switch -c new [<old>] |
    | Move & switch to existing | N/A                    | git switch -m new [<old>] |
    |---------------------------+------------------------+---------------------------|

One thing that sucks about my proposal is that it would be squatting on
"-n" for "new" as opposed to "--dry-run".

It would be nice if switch/checkout learned a --dry-run mode, I don't
like e.g. "fetch" having a "-n" that isn't "--dry-run", but can't think
of a better option in the switch case.

In its current state I find "git switch" to be unusable. That sounds
like dramatic hyperbole, but I'm serious.

As much as I applaud the effort to move git's UI forward in this
particular case it's doomed to be only skin-deep because of that
unfortunate initial design choice of sort-of acting like "git branch
with checkout", but squatting on "-c/-C/-m".

I.e. to me the ideal end state would be to deprecate (or at least
warn/discourage) the "git branch -m" case where it does its own checkout
(but for nothing else), and to make "git switch" a "branch with
checkout" with the same -c/-C/-m/-M semantics, just also with a -n/-N
for "create first".

So at the end of the day you still have to use "git branch" for these
common (at least for me) operations of copy/move, *and* maintain a
mental model that "-c" means "xyz" here, but "abc" there.

The "switch" command also solves the very real problem (and I believe
this was the main motivation) of not knowing beforehand if "checkout"
will interpret your "foo" as a file, a branch or whatever. I find it
easier to solve that (I'm aware that it's not a 100% solution) by
consistently using "--" to escape path names, rather than needing to
mentally model the difference in "-c/-C/-m" behavior.

Re: git switch/restore, still experimental?

[Felipe Contreras]

Ævar Arnfjörð Bjarmason wrote:
> In summary, I think it should be changed to act like this:
>     
>     |---------------------------+------------------------+---------------------------|
>     | What                      | Now                    | New                       |
>     |---------------------------+------------------------+---------------------------|
>     | Switch                    | git switch existing    | git switch existing       |
>     | Error                     | git switch nonexisting | <no change (errors)>      |
>     | Switch with --merge       | git switch -m branch   | git switch --merge branch |
>     | Create                    | git switch -c new      | git switch -n new         |
>     | Create from existing      | N/A                    | git switch -c new [<old>] |
>     | Move & switch to existing | N/A                    | git switch -m new [<old>] |
>     |---------------------------+------------------------+---------------------------|

I'm in favor of this too.

> In its current state I find "git switch" to be unusable. That sounds
> like dramatic hyperbole, but I'm serious.

I concur.

I've tried to use it multiple times, and I always come back to using git
branch / git checkout.

-- 
Felipe Contreras

Re: git switch/restore, still experimental?

[Sergey Organov]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Ævar Arnfjörð Bjarmason wrote:
>> In summary, I think it should be changed to act like this:
>>     
>>     |---------------------------+------------------------+---------------------------|
>>     | What | Now | New |
>>     |---------------------------+------------------------+---------------------------|
>>     | Switch | git switch existing | git switch existing |
>>     | Error | git switch nonexisting | <no change (errors)> |
>>     | Switch with --merge | git switch -m branch | git switch
>>     | --merge branch |
>>     | Create | git switch -c new | git switch -n new |
>>     | Create from existing | N/A | git switch -c new [<old>] |
>>     | Move & switch to existing | N/A | git switch -m new [<old>] |
>>     |---------------------------+------------------------+---------------------------|
>
> I'm in favor of this too.
>
>> In its current state I find "git switch" to be unusable. That sounds
>> like dramatic hyperbole, but I'm serious.
>
> I concur.
>
> I've tried to use it multiple times, and I always come back to using git
> branch / git checkout.

I didn't look at these commands till recently, and what I immediately
noticed is very unclear manual pages. I didn't read entire pages, but
DESCRIPTIONS sections and some options I did check. I think that even if
these commands are to be considered stable by now, the manual pages
themselves need to be heavily revised before removing the EXPERIMENTAL
label.

It'll be worse if unclear manual is just a symptom of unclear design
though.

Thanks,
-- Sergey Organov

Re: git switch/restore, still experimental?

[Sergey Organov]

Æ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?

Thanks,
-- Sergey Organov

Re: git switch/restore, still experimental?

[Junio C Hamano]

Sergey Organov <sorganov@gmail.com> writes:

> 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?

Not really.

The "--autostash" might appear to be applicable to cases that can
induce larger conflict, but once the diversion gets larger than what
one comfortably can deal with "checkout -m", the user is better off
to work by forking a branch there and create a WIP commit, than deal
with the stash.  So if anything, I'd rather get rid of "--autostash"
than "-m", to help users get in a better work habit.

Re: git switch/restore, still experimental?

[Sergey Organov]

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> 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?
>
> Not really.

I tend to disagree. 

> The "--autostash" might appear to be applicable to cases that can
> induce larger conflict,

To me (auto)stash is not about amount of possible conflicts, and even
not about conflicts at all, but rather about data safety. (Auto)stash is
reversible: just get to original branch, apply the stash, and you are
basically back where you was.

Besides, --autostash shouldn't necessarily even imply --autorestore. I
can easily imagine a mode when --autorestore is fired only when one
returns to the branch where --autostash has been performed, leaving to
the user the responsibility of applying the stash to the new branch, if
she really needs it.

OTOH, --merge sounds more like infamous "cvs update". Keep fingers
crossed (or rather do a backup) and push the button, – Git will do its
best not to clobber your content, but all bets are off.

> but once the diversion gets larger than what one comfortably can deal
> with "checkout -m",

The problem is that I suspect there is no such margin. I'm simply
uncomfortable with -m. It doesn't sound safe to me no matter what. I'll
rather stash manually than use -m.

> the user is better off to work by forking a branch there and create a
> WIP commit, than deal with the stash.

Why? This looks like unjustified complication. All this is temporary
enough for the stash proper, – one just forgets about it immediately
most of times, as things typically go rather smooth anyway.

> So if anything, I'd rather get rid of "--autostash" than "-m", to help
> users get in a better work habit.

I have as much as 3 points to oppose to this:

1. Who decides which work habit is better? At the same time, data safety
and recovery are unprejudiced goals to be aimed at.

2. Unlike --merge, --autostash is universal. Whatever job is to be done,
get your changes to a safe place before continuing, to be able get them
back later. It'd be excellent if we had global autostash mode support,
especially if stash were capable to save/restore entire state of
everything. Sounds like "Undo" in text editors, or like automatic backup
before OS update.

3. Dunno about --merge, but I'm sure --autostash came from real life. I
see it all the time how users do "git stash; git pull; git stash pop"
sequence. It's just natural, and if it suits them, who are we to decide
what's "better" for them? I believe Git should continue to provide
convenient tools that help to get the job done, rather than trying to
fight "improper" habits and/or workflows.

Overall, to me --autostash is clear winner :)

That said, I somehow feel this has been already discussed to death when
--autostash was introduced.

Thanks,
-- Sergey Organov

Re: git switch/restore, still experimental?

[Ævar Arnfjörð Bjarmason]

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.

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...

Re: git switch/restore, still experimental?

[Sergey Organov]

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

> 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

Re: git switch/restore, still experimental?

[Junio C Hamano]

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

> I mean, I see why. You don't want a typo of "master" as "maaster" to
> create a new "maaster" branch, so really that's out. But it really
> should be:
>
>     # -n or -N for --new / --new --force (the latter just in case of a
>     # race, and just for consistency)
>     git switch -n doesnotexist

I do not see why --new is better than --create; we did choose not to
reuse --branch from "checkout" and I remember that was a deliberate
decision (i.e. once split into "switch" and "restore", "switch"
becomes only about branches, so unlike in the context of "checkout",
in the context of "switch", the word "branch" adds a lot less value,
and certainly does not signal we are creating a branch and switching
to it).

It would have been a stronger argument to favor --new if we had "git
branch --new <branchname>", but that is not the case.

Re: git switch/restore, still experimental?

[Ævar Arnfjörð Bjarmason]

On Thu, May 06 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I mean, I see why. You don't want a typo of "master" as "maaster" to
>> create a new "maaster" branch, so really that's out. But it really
>> should be:
>>
>>     # -n or -N for --new / --new --force (the latter just in case of a
>>     # race, and just for consistency)
>>     git switch -n doesnotexist
>
> I do not see why --new is better than --create; we did choose not to
> reuse --branch from "checkout" and I remember that was a deliberate
> decision (i.e. once split into "switch" and "restore", "switch"
> becomes only about branches, so unlike in the context of "checkout",
> in the context of "switch", the word "branch" adds a lot less value,
> and certainly does not signal we are creating a branch and switching
> to it).

I don't think --new is better than --create when considered in
isolation. I happen to think --create is better.

What I'm arguing is that we should be aiming for some consistency in the
command-set. In this case the relatively small change of
s/--create/--new/ server so make the rest consistent. I.e. the branch
and switch commands can mirror each other in the ways that matter for
these common operations of create/copy/move.

> It would have been a stronger argument to favor --new if we had "git
> branch --new <branchname>", but that is not the case.

The argument is that switch's experimental design squats on 2x other
options, so changing -c to -n so we can make -c and -m do the same thing
is better.

Re: git switch/restore, still experimental?

[Ævar Arnfjörð Bjarmason]

On Thu, May 06 2021, Ævar Arnfjörð Bjarmason wrote:

> On Thu, May 06 2021, Junio C Hamano wrote:

*Poke*

>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>>> I mean, I see why. You don't want a typo of "master" as "maaster" to
>>> create a new "maaster" branch, so really that's out. But it really
>>> should be:
>>>
>>>     # -n or -N for --new / --new --force (the latter just in case of a
>>>     # race, and just for consistency)
>>>     git switch -n doesnotexist
>>
>> I do not see why --new is better than --create; we did choose not to
>> reuse --branch from "checkout" and I remember that was a deliberate
>> decision (i.e. once split into "switch" and "restore", "switch"
>> becomes only about branches, so unlike in the context of "checkout",
>> in the context of "switch", the word "branch" adds a lot less value,
>> and certainly does not signal we are creating a branch and switching
>> to it).
>
> I don't think --new is better than --create when considered in
> isolation. I happen to think --create is better.
>
> What I'm arguing is that we should be aiming for some consistency in the
> command-set. In this case the relatively small change of
> s/--create/--new/ server so make the rest consistent. I.e. the branch
> and switch commands can mirror each other in the ways that matter for
> these common operations of create/copy/move.
>
>> It would have been a stronger argument to favor --new if we had "git
>> branch --new <branchname>", but that is not the case.
>
> The argument is that switch's experimental design squats on 2x other
> options, so changing -c to -n so we can make -c and -m do the same thing
> is better.

Whatever the merit of the argument I'm putting forward here, it would be
useful to get some idea of whether you'd be categorically opposed to
changing the interface of switch/restore in breaking ways even though
they've been marked as "THIS COMMAND IS EXPERIMENTAL".

Of course any series to implement what I suggested in
<877dkdwgfe.fsf@evledraar.gmail.com> would need to stand on its own
merits.

I'm not planning on working on that since I expect the response will be
at best "neat, but that ship has sailed", but if that's not the case...

Re: git switch/restore, still experimental?

[Junio C Hamano]

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

>>> It would have been a stronger argument to favor --new if we had "git
>>> branch --new <branchname>", but that is not the case.
>>
>> The argument is that switch's experimental design squats on 2x other
>> options, so changing -c to -n so we can make -c and -m do the same thing
>> is better.
>
> Whatever the merit of the argument I'm putting forward here, it would be
> useful to get some idea of whether you'd be categorically opposed to
> changing the interface of switch/restore in breaking ways even though
> they've been marked as "THIS COMMAND IS EXPERIMENTAL".
>
> Of course any series to implement what I suggested in
> <877dkdwgfe.fsf@evledraar.gmail.com> would need to stand on its own
> merits.
>
> I'm not planning on working on that since I expect the response will be
> at best "neat, but that ship has sailed", but if that's not the case...

cf. <xmqqzgx81x2q.fsf@gitster.g>

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

>>Which leaves us with two hard choices regarding switch/restore, none of them
>>really being comfortable:
>>
>>- we scrap switch/restore because their usability is not really all that
>>  improved relative to `git checkout`.
>
> Please do not do that. Switch/restore is much easier to understand
> for new users. The semantics are also more consistent with what
> others have done with git over the years anyway (EGit as an
> example). I have users who have transitioned because the commands
> make sense. They have not hit any missing bits in their workflows.
>
>>- we leave switch/restore as-are (because by now, changing the options or
>>  the design would be almost certainly disruptive to users who already
>>  tried to adopt the new commands, I being one of those users).
>
> I think we should work on the commands to cover between them
> (well... and reset) to functionally cover what checkout
> does. Leaving them as-is, I think is not a viable option. People
> do know these are experimental and not to use in scripts - we can
> hope anyway.

Yeah, I tend to agree with you that the third-choice to improve
switch/restore before we can confidently say they are no longer
"experimental" would be much nicer than giving up on them too early.

Re: git switch/restore, still experimental?

[Felipe Contreras]

Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > I mean, I see why. You don't want a typo of "master" as "maaster" to
> > create a new "maaster" branch, so really that's out. But it really
> > should be:
> >
> >     # -n or -N for --new / --new --force (the latter just in case of a
> >     # race, and just for consistency)
> >     git switch -n doesnotexist
> 
> I do not see why --new is better than --create;

I do. Different languages equal different minds.

New in this context is an adjetive: it is a modifier of a noun, in this
case, a branch.

Create is a verb; it's an action.

Linguistically speaking they could not be more different.


You don't do two verbs at a time. Either you sleep, or you eat, but you
don't do both. Similarly you don't switch and create. Doesn't make
sense.

If you use natural language:

  1. Git, switch to a new branch

  2. Git, switch, create, branch

One of these simply flows, the other is complete gibberish. I think
anyone familiar with English can identify which is which.

Cheers.

-- 
Felipe Contreras

Re: git switch/restore, still experimental?

[Ævar Arnfjörð Bjarmason]

On Thu, May 06 2021, Felipe Contreras wrote:

> Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> 
>> > I mean, I see why. You don't want a typo of "master" as "maaster" to
>> > create a new "maaster" branch, so really that's out. But it really
>> > should be:
>> >
>> >     # -n or -N for --new / --new --force (the latter just in case of a
>> >     # race, and just for consistency)
>> >     git switch -n doesnotexist
>> 
>> I do not see why --new is better than --create;
>
> I do. Different languages equal different minds.
>
> New in this context is an adjetive: it is a modifier of a noun, in this
> case, a branch.
>
> Create is a verb; it's an action.
>
> Linguistically speaking they could not be more different.
>
>
> You don't do two verbs at a time. Either you sleep, or you eat, but you
> don't do both. Similarly you don't switch and create. Doesn't make
> sense.
>
> If you use natural language:
>
>   1. Git, switch to a new branch
>
>   2. Git, switch, create, branch
>
> One of these simply flows, the other is complete gibberish. I think
> anyone familiar with English can identify which is which.

Well, there's "Git, create a new branch and switch to it"

Also, there's the verb "make" in common use in git's command set
e.g. git-mktag, git-mktree, as well as mkdir(1), mkfifo(1) etc.

Perhaps we'd be better off with a git-mkbranch in this case & leave "git
branch" as an interrogation/change command.

In any case, unless we're talking about rewamping git's entire command
set (e.g. having a git-newtree or whatever) I'd like to think that it's
more productive to focus on making the commands/switches we have
internally consistent when possible, which is what I'm advocating in the
E-Mail that started this sub-thread.

Re: git switch/restore, still experimental?

[Felipe Contreras]

Ævar Arnfjörð Bjarmason wrote:
> On Thu, May 06 2021, Felipe Contreras wrote:

> > If you use natural language:
> >
> >   1. Git, switch to a new branch
> >
> >   2. Git, switch, create, branch
> >
> > One of these simply flows, the other is complete gibberish. I think
> > anyone familiar with English can identify which is which.
> 
> Well, there's "Git, create a new branch and switch to it"

Which command is that?

  git create branch --checkout?

I'm following the order of the words from left to right.

> Also, there's the verb "make" in common use in git's command set
> e.g. git-mktag, git-mktree, as well as mkdir(1), mkfifo(1) etc.

Sure, although I wouldn't consider them main commands. I for one never
use them.

> In any case, unless we're talking about rewamping git's entire command
> set (e.g. having a git-newtree or whatever) I'd like to think that it's
> more productive to focus on making the commands/switches we have
> internally consistent when possible, which is what I'm advocating in the
> E-Mail that started this sub-thread.

But we are talking about a new command, it is precisely at this point we
need to think about what could have been if mistakes of the past had not
happened.

We should not repeat past mistakes without a very good reason.

I don't think we should seek consistency for consistency's sake. Sure,
consistency is good, but it's only one of many considerations.

In this case however we have a rare occasion in which both consistency and
natural language meet, we should not squander it.

In fact, to be even more consistent we could add a -n option to git
branch, which would be reduntant but more explicit, like --list.

Cheers.

-- 
Felipe Contreras

Re: git switch/restore, still experimental?

[Ævar Arnfjörð Bjarmason]

On Thu, May 06 2021, Felipe Contreras wrote:

> Ævar Arnfjörð Bjarmason wrote:
>> On Thu, May 06 2021, Felipe Contreras wrote:

First of all, I think we're in rather violent agreement about the real
matter at hand here, and are at best talking about the design of the
keychain for the bikeshed...

>> > If you use natural language:
>> >
>> >   1. Git, switch to a new branch
>> >
>> >   2. Git, switch, create, branch
>> >
>> > One of these simply flows, the other is complete gibberish. I think
>> > anyone familiar with English can identify which is which.
>> 
>> Well, there's "Git, create a new branch and switch to it"
>
> Which command is that?
>
>   git create branch --checkout?
>
> I'm following the order of the words from left to right.

I'm just pointing out that git in general and certainly not the *nix
tradition it follows tries to make commands readable in anything like
English sentence order. If you attempt to read "log", "status", "rebase"
etc. commands like that you'll at best end up sounding somewhat like
Yoda.

>> Also, there's the verb "make" in common use in git's command set
>> e.g. git-mktag, git-mktree, as well as mkdir(1), mkfifo(1) etc.
>
> Sure, although I wouldn't consider them main commands. I for one never
> use them.
>
>> In any case, unless we're talking about rewamping git's entire command
>> set (e.g. having a git-newtree or whatever) I'd like to think that it's
>> more productive to focus on making the commands/switches we have
>> internally consistent when possible, which is what I'm advocating in the
>> E-Mail that started this sub-thread.
>
> But we are talking about a new command, it is precisely at this point we
> need to think about what could have been if mistakes of the past had not
> happened.
>
> We should not repeat past mistakes without a very good reason.
>
> I don't think we should seek consistency for consistency's sake. Sure,
> consistency is good, but it's only one of many considerations.
>
> In this case however we have a rare occasion in which both consistency and
> natural language meet, we should not squander it.
>
> In fact, to be even more consistent we could add a -n option to git
> branch, which would be reduntant but more explicit, like --list.

Indeed, I agree with all of that. I.e. we should move to "switch" to
"-n" instead of "-c" etc., and add a "-n" to "branch" for
consistency. After all that's my upthread proposal...

I just don't think it's worth trying to make the argv readable as a
sentence, even if we had no backwards compatibility to worry about.

Re: git switch/restore, still experimental?

[Felipe Contreras]

Ævar Arnfjörð Bjarmason wrote:
> On Thu, May 06 2021, Felipe Contreras wrote:
> 
> First of all, I think we're in rather violent agreement about the real
> matter at hand here, and are at best talking about the design of the
> keychain for the bikeshed...

Indeed. The design of the hypothetical keychain for future bikesheds.

> > Which command is that?
> >
> >   git create branch --checkout?
> >
> > I'm following the order of the words from left to right.
> 
> I'm just pointing out that git in general and certainly not the *nix
> tradition it follows tries to make commands readable in anything like
> English sentence order. If you attempt to read "log", "status", "rebase"
> etc. commands like that you'll at best end up sounding somewhat like
> Yoda.

Right, but git is infamous for having a UI that leaves a lot to be
desired. I'm less concerned about the status quo of git's UI than I am
of what could be.

Inertia is something that just can't be ignored on commands that people
have been using for 15 years.

My point is that new commands should not follow the inertia of old
commands, especially when we know that historically the UI is the thing
that needs more improvements. In fact, we should do the *opposite*. It's
the less-than-stellar UI that created the need for switch/restore in the
first place.

> > In this case however we have a rare occasion in which both consistency and
> > natural language meet, we should not squander it.
> >
> > In fact, to be even more consistent we could add a -n option to git
> > branch, which would be reduntant but more explicit, like --list.
> 
> Indeed, I agree with all of that. I.e. we should move to "switch" to
> "-n" instead of "-c" etc., and add a "-n" to "branch" for
> consistency. After all that's my upthread proposal...
> 
> I just don't think it's worth trying to make the argv readable as a
> sentence, even if we had no backwards compatibility to worry about.

Well, we would need to look at particular examples to see if the
counter-examples make more sene or not.

Either way my contention is that it doesn't hurt.

I will take a look at switch/restore and see if a linguist approach
gives more low-hanging fruit.

Fortunately none of that matters for your particular proposal which is
just good.

Cheers.

-- 
Felipe Contreras

Re: git switch/restore, still experimental?

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 2966 bytes --]

Hi Elijah,

On Tue, 4 May 2021, Elijah Newren wrote:

> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:
> >
> > 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?
>
> 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 think that part of the intention to mark this as experimental was to
gather feedback about the commands. After all, the goal was to improve the
user experience of Git (because `git checkout` does too many things, and
its major accomplishment is to confuse literally every single new Git
user).

However, that hope never was fulfilled if I may say so, we simply did not
attract the best-suited experts to this mailing list, not if what we set
out was to improve usability.

Which leaves us with two hard choices regarding switch/restore, none of
them really being comfortable:

- we scrap switch/restore because their usability is not really all that
  improved relative to `git checkout`.

- we leave switch/restore as-are (because by now, changing the options or
  the design would be almost certainly disruptive to users who already
  tried to adopt the new commands, I being one of those users).

I say that neither of them is a really splendid choice because the
original goal is not only not accomplished, but I would say it is even
harder now than it was when we accepted switch/restore into an official
release, because of that experience with switch/restore. We simply do not
have the right expertise on this list, and therefore anything we do will
always have that "UX designed by an engineer" feel.

So I'm not sure what to do, either.

Ciao,
Dscho

> That said, we're only a few weeks from -rc0, and I'd rather remove the
> experimental label early in a release cycle, so maybe this would be a
> good thing to do after the June git-2.32 release.  That'd give plenty
> of time for others to chime in with anything they might be aware of
> that they want or need fixed.
>
> Thanks for flagging this.
>
> Elijah
>

RE: git switch/restore, still experimental?

[Randall S. Becker]

On May 5, 2021 10:18 AM, Johannes Schindelin wrote:
>On Tue, 4 May 2021, Elijah Newren wrote:
>> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com>
>wrote:
>> >
>> > 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?
>>
>> 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 think that part of the intention to mark this as experimental was to gather
>feedback about the commands. After all, the goal was to improve the user
>experience of Git (because `git checkout` does too many things, and its major
>accomplishment is to confuse literally every single new Git user).
>
>However, that hope never was fulfilled if I may say so, we simply did not attract
>the best-suited experts to this mailing list, not if what we set out was to improve
>usability.
>
>Which leaves us with two hard choices regarding switch/restore, none of them
>really being comfortable:
>
>- we scrap switch/restore because their usability is not really all that
>  improved relative to `git checkout`.

Please do not do that. Switch/restore is much easier to understand for new users. The semantics are also more consistent with what others have done with git over the years anyway (EGit as an example). I have users who have transitioned because the commands make sense. They have not hit any missing bits in their workflows.

>- we leave switch/restore as-are (because by now, changing the options or
>  the design would be almost certainly disruptive to users who already
>  tried to adopt the new commands, I being one of those users).

I think we should work on the commands to cover between them (well... and reset) to functionally cover what checkout does. Leaving them as-is, I think is not a viable option. People do know these are experimental and not to use in scripts - we can hope anyway.

>I say that neither of them is a really splendid choice because the original goal is
>not only not accomplished, but I would say it is even harder now than it was
>when we accepted switch/restore into an official release, because of that
>experience with switch/restore. We simply do not have the right expertise on
>this list, and therefore anything we do will always have that "UX designed by an
>engineer" feel.

My thoughts anyway.

-Randall

Re: git switch/restore, still experimental?

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

>>Which leaves us with two hard choices regarding switch/restore, none of them
>>really being comfortable:
>>
>>- we scrap switch/restore because their usability is not really all that
>>  improved relative to `git checkout`.
>
> Please do not do that. Switch/restore is much easier to understand
> for new users. The semantics are also more consistent with what
> others have done with git over the years anyway (EGit as an
> example). I have users who have transitioned because the commands
> make sense. They have not hit any missing bits in their workflows.
>
>>- we leave switch/restore as-are (because by now, changing the options or
>>  the design would be almost certainly disruptive to users who already
>>  tried to adopt the new commands, I being one of those users).
>
> I think we should work on the commands to cover between them
> (well... and reset) to functionally cover what checkout
> does. Leaving them as-is, I think is not a viable option. People
> do know these are experimental and not to use in scripts - we can
> hope anyway.

Yeah, I tend to agree with you that the third-choice to improve
switch/restore before we can confidently say they are no longer
"experimental" would be much nicer than giving up on them too early.

Re: git switch/restore, still experimental?

[Felipe Contreras]

Johannes Schindelin wrote:
> Which leaves us with two hard choices regarding switch/restore, none of
> them really being comfortable:
> 
> - we scrap switch/restore because their usability is not really all that
>   improved relative to `git checkout`.
> 
> - we leave switch/restore as-are (because by now, changing the options or
>   the design would be almost certainly disruptive to users who already
>   tried to adopt the new commands, I being one of those users).

There's another option:

 - we revamp completely switch/restore (because any users relying on
   them by now were warned they shouldn't assume these commands to stay
   as they are).

> I say that neither of them is a really splendid choice because the
> original goal is not only not accomplished, but I would say it is even
> harder now than it was when we accepted switch/restore into an official
> release, because of that experience with switch/restore. We simply do not
> have the right expertise on this list, and therefore anything we do will
> always have that "UX designed by an engineer" feel.

I disagree. Engineers can create a good UI, especially after trying
for a while failed attempts.

Cheers.

-- 
Felipe Contreras