On Wed, Feb 20, 2019 at 4:19 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > 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. There is a trade off somewhere. "new user first" should not come at the cost for more experienced users. Making "git checkout/merge" abort while it's working before breaks scripts. And requiring to mark trashable files manually duplicates a lot of ignore patterns. Have a look at any .gitignore file, the majority of them is for discardable files because "ignored" class was created with those in mind (*.o and friends). So now you would need to add more or less the same set of ignore rules in .gitattributes to mark them trashable, and gitignore/gitattributes rules are not exactly compatible, you can't just blindly copy them over. Every time you add one more .gitignore rule, there's a good chance you need to add a similar rule for trashable attribute. Maybe we just add a new "newbie" config knob and turn on the safety nets on. Leave the knob on by default. And I will turn it off in my ~/.gitconfig as soon as it's real. -- Duy
