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

From: Duy Nguyen <pclouds@gmail.com>
Date: Nov 12, 2018, 16:07 UTC
Message-ID: <CACsJy8C3rOFv0kQeJrWufQQzbnfU4mSxJtphEYBGMmrroFFN-A@mail.gmail.com>
In-Reply-To: <1205132135.1189562.1542013731020.JavaMail.zimbra@matthieu-moy.fr>

On Mon, Nov 12, 2018 at 10:09 AM Matthieu Moy <git@matthieu-moy.fr> wrote:

Show 9 quoted lines

> May I remind an idea I sugested in an old thread: add an intermediate level
> where ignored files to be overwritten are renamed (eg. foo -> foo~ like Emacs'
> backup files):
>
> https://public-inbox.org/git/vpqd3t9656k.fsf@bauges.imag.fr/
>
> One advantage of the "rename" behavior is that it's safer that the current,
> but still not very disturbing for people who like the current behavior. This
> makes it a good candidate for a default behavior.

I have something else in the bag that does something like this. The idea is that we go ahead and do destructive things but we let the user undo.

Some more background in [1] but basically we hash "every" change and store in the object database (in this case we store "foo" content before overwriting it). We maintain a list of these hashes so that undo is possible, but of course we don't keep infinite change history, eventually too old changes will be pruned. [1] talks about index changes (e.g. "git add -p") but it could apply to worktree changes as well (and I'm also eyeing $GIT_DIR/config changes).

The upside: a similar undo mechanism that works for more than just this case and it allows undoing multiple times while foo~ only allow once. The downside: hashing is definitely heavier than renaming foo to foo~. So this will feature be opt-in in most cases. But for "dangerous" overwrite like this case, I think we value the file content more and make it opt-out.

[1] https://public-inbox.org/git/CACsJy8A3QCYY6QeJQYkbCKYh=7Q7pj=rer_OQHLGoAMqTNomNA@mail.gmail.com/

-- 
Duy