On Wed, Feb 20, 2019 at 1:08 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Duy Nguyen <pclouds@xxxxxxxxx> writes: > > > 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. > > 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. I think the sticking point is how to deal with the surprise factor and "precious" will not help at all in this aspect. In my mind there are three classes - total expectation, i know i want git to not touch some files, i tell git so (e.g. with "precious") - surprises sometimes, but in known classes. This is the main use case of backup log, where I may accidentally do "git commit -amsomething" after carefully preparing the index. Saving overwritten files by merge/checkout could be done here as an alternative to "garbage" attribute. > 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. If we do a good job in > supporting "precious" in various operations, we can rely less on > "backup log" and still be safe ;-) and this is the third class, something completely unexpected. Yes backup-log can't help here, but I don't think "precious" can either. And I have no good proposal for this case. -- Duy
