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
