Re: [RFC PATCH] Introduce "precious" file concept

From: Duy Nguyen <pclouds@gmail.com>
Date: Dec 1, 2018, 06:21 UTC
Message-ID: <CACsJy8D7rypM-0gYx3Xtx0jDQ=xMO2GxEmf6Mvc84Ch3AnSkug@mail.gmail.com>
In-Reply-To: <875zwgzx4v.fsf@evledraar.gmail.com>

On Wed, Nov 28, 2018 at 10:54 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 16 quoted lines

> 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@gitster-ct.c.googlers.com/
> 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@gmail.com/

-- 
Duy