On Wed, Nov 28, 2018 at 10:54 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > But we must have some viable way to repair warts in the tools, and > losing user data is a *big* wart. > > I don't think something like the endgame you've described in > https://public-inbox.org/git/xmqqzhtwuhpc.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/ > is ever going to work. Novice git users (the vast majority) are not > going to diligently update both .gitignore and some .gitattribute > mechanism in lockstep. I'd bet most git users haven't read more than a > few paragraphs of our entire documentation at best. > > So what's the way forward? I think ultimately we must move to something > where we effectively version the entire CLI UI similar to stable API > versions. I.e. for things like this that would break some things (or > Duy's new "split checkout") introduce them as flags first, then bundle > up all such flags and cut a major release "Git 3, 4, ...", and > eventually remove old functionality. Related to Duy's new "split chekckout", I just realized that I added --overwrite-ignore (enabled by default) [1] years ago to allow to out out of this behavior. We could turn --no-overwrite-ignore by default on the new command "git switch-branch" to err on the safe side. Then the user could switch to --overwrite-ignore once they learn more about gitignore and gitattributes (or the coming "backup log"). I'm not sure if I really like this, but at least it's one of the options. [1] https://public-inbox.org/git/1322388933-6284-2-git-send-email-pclouds@xxxxxxxxx/ -- Duy
