On Tue, Nov 27, 2018 at 1:45 AM Per Lundberg <per.lundberg@xxxxxxxx> wrote: > > On 11/26/18 5:55 PM, Duy Nguyen wrote: > > On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason > > <avarab@xxxxxxxxx> wrote: > >> 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
