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. [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. -- Duy
