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

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

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.

 b) For the general problem of "user has exotic config" we should learn
    a "git -Q <cmd>" option similar to Emacs, which is another highly
    customizable piece of software that has a "don't read user config"
    escape hatch.

    That's a bit more complex than for Emacs since we need to actually
    read some config (e.g. remote config from .git/config), and maybe
    opt to keep some stuff like user.*. But there's no reason we can't
    have such a black/whitelist of config & env variables that impact us
    with a switch to get "make it as if nothing was configured" for
    whatever sane version of that we'd come up with.