On Sun, Feb 17 2019, Duy Nguyen wrote: > On Sun, Feb 17, 2019 at 2:36 AM Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: >> >> >> On Sat, Feb 16 2019, Nguyễn Thái Ngọc Duy wrote: >> >> [Re-CC some people involved the last time around] >> >> > A new attribute "precious" is added to indicate that certain files >> > have valuable content and should not be easily discarded even if they >> > are ignored or untracked. >> > >> > So far there are one part of Git that are made aware of precious >> > files: "git clean" will leave precious files alone. >> >> Thanks for bringing this up again. There were also some patches recently >> to save away clobbered files, do you/anyone else have any end goal in >> mind here that combines this & that, or some other thing I may not have >> kept up with? > > I assume you mean the clobbering untracked files by merge/checkout. > Those files will be backed up [1] if backup-log is implemented. Even > files deleted by "git clean" could be saved but that might go a little > too far. And I suppose if we have some mechanism for "don't backup but error out if it was detectes as needed" we'll have the equivalent of inverting the merge/checkout --force behavior now (& my "garbage" patch), i.e. we'd stall on potential clobbering and need to carry on with --force. > [1] https://public-inbox.org/git/20181209104419.12639-20-pclouds@xxxxxxxxx/ > >> My commentary on this whole thing is basically a repeat of what I said >> in https://public-inbox.org/git/87wop0yvxv.fsf@xxxxxxxxxxxxxxxxxxx/ >> >> I.e. we have a definite problem here somewhere, and there is some >> solution, but this patch feels a bit like navigating that maze in the >> dark without a map. >> >> We had users report that the likes of "pull" were eating their data, but >> now with this iteration of "precious" only impacting "clean" the only >> problem anyone with the current semantics is still left unaddressed. My >> memory (I may be wrong) is that "clean" was just brought up (by you?) as >> a "what about this other related case?" in that whole discussion. >> >> So as noted in the E-Mail linked above I think the first step should be >> to enumerate/document/test the cases where we're now eating data >> implicitly, and discuss how that relates to the semantics we desired >> when the data-eating behavior was first introduced (as noted in E-Mails >> linked from the above, my own preliminary digging seems to reveal there >> isn't much of a relationship between the two). >> >> Only when we have that list of XYZ cases we're supporting now, and can >> see that XYZ is so important to maintain backwards compatibility for >> that we can't change it should way say "we eat your data by default >> because XYZ is so useful/backcompat, set 'precious' ...". >> >> But right now we don't even have the list of XYZ or tests for them (as >> my RFC "garbage" attribute patch revealed). So this whole thing still >> feels like jumping three steps ahead to me in terms of addressing *that* >> issue, but perhaps you have some orthogonal use-case in mind for this? > > I'm not addressing the accidentally losing data in this patch. My > answer for that would still be backup-log, if it ever gets merged. But > this patch is about _known_ files that I want to keep when doing "git > clean", no more. Indeed. My concern is that we're making incremental steps without a clear idea of the end state, and once we get there we might find that some steps along the way box us in or weren't what we wanted to solve the overall UX issue. More so in the CL / commit message not describing where we are overall, where this patch fits in (backup log, etc.) than this whole thing (backup log is already 24 patches) needing to be sent as one giant series...
