On Tue, Nov 27, 2018 at 1:56 PM Jacob Keller <jacob.keller@xxxxxxxxx> wrote: > > 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. Yes I know it will delete ignored files. But I don't want it to delete some files. There is no way I can tell Git to do that. It's the same with merge/checkout's overwriting problem. Once the initial surprise is over, I want control over what files I want Git to just delete and not annoy me, what Git should not delete. -- Duy
