Re: [PATCH 1/1] Introduce "precious" file concept

[Duy Nguyen <pclouds@gmail.com>]

On Sun, Feb 17, 2019 at 2:36 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> 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@gmail.com/

> My commentary on this whole thing is basically a repeat of what I said
> in https://public-inbox.org/git/87wop0yvxv.fsf@evledraar.gmail.com/
>
> 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