From: Thomas Guyot <tguyot@gmail.com>
Date: Mon, 10 Apr 2023 13:32:26 GMT
Subject: Re: Add a way to disable «git clean» per repo
Message-ID: <37127bb2-8fa2-5908-6824-bb9be9bb0c3b@gmail.com>
In-Reply-To: <ZDLvUxp0d33VgFQY@thunder.hadrons.org>

On 2023-04-09 13:01, Guillem Jover wrote:
>> I doubt it would make much sense to file a feature request to Debian
>> or GNU/FSF to disable "rm -r" in certain directories.  I am not sure
>> why "git clean" should be any different.
> Right, but I see a substantial difference though, «git clean» is
> part of the git toolset to manage among other things specific work
> trees, where that behavior is controlled through configuration, and
> is as such confined within those specific realms, where also the
> properties of what is being tracked might be different.
> (With GNU coreutils rm you can confine it within one filesystem with
> --one-file-system, but TBH I've never had the need to use it AFAIR,
> and it's not enabled by default.)
>

Hi Guillem,

I agree with Junio here - there are many ways you could adapt your use 
of Git to safely manage these types of repos... for starters I don't 
like storing the .git directly in the folders I'm tracking, I always use 
separate repos with a script to compare the contents vs the real 
filesystem. Something like:


#!/bin/sh
diff -ur `hostname -s`/ / |grep -v "^Only in /"


In this example the repo tracks files from / on multiple hosts using 
hostname as the first component; diff won't descend into "new" dirs so 
this runs very fast too, and can be piped to diffstat to get a summary 
of changed files.


Also if you fear accidentally recalling a dangerous clean command from 
history, you can set HISTCONTROL=ignoreboth then prefix any dangerous 
command with a space, or use HISTIGNORE to selectively ignore got clean 
commands. That works with other dangerous commands like sudo reboot, rm 
-rf, etc...


The HISTCONTROL way is even better imho as I would always save/recall 
the command with -n appended (no-op) to review what would be done (ex 
sometimes there could be a virtualenv in the way that I forgot to remove 
from ignores) and only when I'm happy I'd remove the -n and insert a 
space in front so the command doesn't get saved.

Regards,

-- 
Thomas