Thread (30 messages) 30 messages, 8 authors, 2018-12-06

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

flat view

From: Jacob Keller <hidden>
Date: 2018-11-27 12:56:05

On Tue, Nov 27, 2018 at 1:45 AM Per Lundberg [off-list ref] wrote:
On 11/26/18 5:55 PM, Duy Nguyen wrote:
quoted
On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
Some of the solutions overlap with this thing you want, but I think it's
worth keeping the distinction between the two in mind.
On the other hand all use cases should be considered. It's going to be
a mess to have "trashable" attribute that applies to some commands
while "precious" to some others (and even worse when they overlap,
imagine having to define both in .gitattributes)
Agree - I think it would be a very bad idea to have a "mix" of both
trashable and precious. IMO, we should try to find which one of these
concepts suits most general use cases best and causes less churn for
existing scripts/users' existing "semantic expectations", and pick that one.
--
Per Lundberg
Personally, I would rather err on the side which requires the least
interaction from users to avoid silently clobbering an ignored file.

Either Duy's solution with a sort of "untracked" reflog, or the
garbage/trashable notion.

I don't like the idea of precious because it means people have to know
and remember to opt in, and it's quite possible they will not do so
until after they've lost real data.

I'd only have trashable apply in the case where it was implicit. i.e.
git clean -fdx would still delete them, as this is an explicit
operation that (hopefully?) users know will delete data.

Thanks,
Jake
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help