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

>
>
> On Fri, Nov 30 2018, Duy Nguyen wrote:
>
> > On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
> > <avarab@gmail.com> wrote:
> >> 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.
> >
> > core.uiVersion is a big no no to me. I don't want to go to someone's
> > terminal, type something and have a total surprise because they set
> > different ui version. If you want a total UI redesign, go with a new
> > prefix, like "ng" (for new git) or something instead of "git".
>
> I don't think that's a viable way forward. First, we're not talking
> about a total change of the UI. Most the main porcelain will stay the
> same. So we'd have a "ng" that's >98% the same UI, and then if we
> discover warts in in 10 years we'd like to fix then what do wo do? Ship
> "nng" and so forth?

> We already have this UI problem with various config variables that
> change things. I think we should just solve this general issue by a
> combination of:
>
>  a) Accepting that over the long term we will have Git's UI changing,
>     sometimes in breaking ways (with sensible phase-in), hopefully for
>     the better. E.g. we had this with "git-init" v.s. "git init". This
>     is similar, there'd be an error due to ambiguity with a "hint"
>     saying use the new thing if you e.g. feed "git checkout" a branch
>     name.