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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Feb 19 2019, Junio C Hamano wrote:

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> 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.
>
> I agree with Ævar that it is a very good idea to ask what the
> endgame should look like.  I would have expected that, with an
> introduction of new "ignored but unexpendable" class of file
> (i.e. "precious" here), operations such as merge and checkout will
> be updated to keep them in situations where we would remove "ignored
> and expendable" files (i.e. "ignored").  And it is perfectly OK if
> the very first introduction of the "precious" support begins only
> with a single operation, such as "clean", as long as the end-goal is
> clear.

FWIW I'm in full agreement with that.

> I personally do not believe in "backup log"; if we can screw up and
> can fail to stop an operation that must avoid losing info, then we
> can screw up the same way and fail to design and implement "backup"
> to save info before an operation loses it.

Yes, there could be some unforseen interaction between git commands
where we should have such a backup log, but did not think to implement
it. I'd hope such cases would be reported, and we could fix them.

But those sorts of cases aren't why we started discussing this, rather
we *know* what the data shredding command interaction is, but there
wasn't a consensus for just not shredding data by default by making
users use "checkout -f" or "merge -f" to proceed. I.e. taking some
variant of my "trashable" patch[1].

> If we do a good job in
> supporting "precious" in various operations, we can rely less on
> "backup log" and still be safe ;-)

Is noted in previous discussions[2] I think that's entirely
implausible. I think at best the "precious" facility will be used to
mark e.g *.o files as "don't check in, but don't clean (Makefile handles
it)".

Most git users are at the level of only knowing very basic
add/commit/pull/push command interaction. I feel strongly that we need
to make our tools safe to use by default, and not require some
relatively advanced "precious"/attribute facility to be carefully
configured in advance so we don't throw away uncommitted work on the
likes of merge/checkout.

1. https://public-inbox.org/git/87zhuf3gs0.fsf@evledraar.gmail.com/
2. https://public-inbox.org/git/871s7r4wuv.fsf@evledraar.gmail.com/