On Fri, Nov 30, 2018 at 12:29 PM Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > > > On Fri, Nov 30 2018, Duy Nguyen wrote: > > > On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason > > <ava...@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?
Yes. So think it through and try not to do it often. > 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. And I hate adding a zillion of config keys to change little things like this. Now you use this to change bigger behavior. No. -- Duy
