Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote:

> v3 sees switch-branch go back to switch-branch (in v2 it was
> checkout-branch). checkout-files is also renamed restore-files (v1 was
> restore-paths). Hopefully we won't see another rename.
>
> I'll try to summarize the differences between the new commands and
> 'git checkout' down here, but you're welcome to just head to 07/14 and
> read the new man pages.
>
> 'git switch-branch'
>
> - does not "do nothing", you have to either switch branch, create a
>   new branch, or detach. "git switch-branch" with no arguments is
>   rejected.
>
> - implicit detaching is rejected. If you need to detach, you need to
>   give --detach. Or stick to 'git checkout'.
>
> - -b/-B is renamed to -c/-C with long option names
>
> - of course does not accept pathspec
>
> 'git restore-files'
>
> - takes a ref from --from argument, not as a free ref. As a result,
>   '--' is no longer needed. All non-option arguments are pathspec
>
> - pathspec is mandatory, you can't do "git restore-files" without any
>   pathspec.
>
> - I just remember -p which is allowed to take no pathspec :( I'll fix
>   it later.
>
> - Two more fancy features (the "git checkout --index" being the
>   default mode and the backup log for accidental overwrites) are of
>   course still missing. But they are coming.
>
> I did not go replace "detached HEAD" with "unnamed branch" (or "no
> branch") everywhere because I think a unique term is still good to
> refer to this concept. Or maybe "no branch" is good enough. I dunno.

I finally tracked down
https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1
which I'd remembered reading and couldn't find again in these
discussions. Re-reading it while one may not 100% agree with the
author's opinion, it's an interesting rabbit hole.

I also didn't know about EasyGit, or that Elijah Newren had written
it. I haven't seen him chime in on this series, and would be interested
to see what he thinks about it.

Re the naming question in
https://public-inbox.org/git/87o9abzv46.fsf@evledraar.gmail.com/ &
seeing that eg-switch exists, I wonder if just s/switch-branch/switch/
makes more sense.

Assuming greenfield development (which we definitely don't have), I
don't like the "restore-files" name, but the alternative that makes
sense is "checkout". Then this "--from" argument could become "git
checkout-tree <treeish> -- <pathspec>", and we'd have:

    git switch <branchish>
    git checkout <pathspec>
    git checkout-tree <treeish> -- <pathspec>

Or maybe that sucks, anyway what I was going to suggest is *if* others
think that made sense as a "if we designed git today" endgame whether we
could have an opt-in setting where you set e.g. core.uiVersion=3 (in
anticipation of Git 3.0) and you'd get that behavior. There could be
some other setting where core.uiVersion would use the old behavior (or
with another setting, only warn) if we weren't connected to a terminal.

I.e. I'm thinking of this as step #2 in a #3 step series. Where this is
the fully backwards compatible UI improvement, but someone who'd
e.g. use EasyGit or didn't have backwards compatibility concerns could
enable step #3 and opt-in to a mode where we'd fixed a bunch of UI warts
in a backwards-incompatible way.

What would that mode look like? I'd to work on piling that on top of
this :)