From: Thomas Guyot <tguyot@gmail.com>
To: Guillem Jover <guillem@hadrons.org>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: Add a way to disable «git clean» per repo
Date: Mon, 10 Apr 2023 09:32:26 -0400 [thread overview]
Message-ID: <37127bb2-8fa2-5908-6824-bb9be9bb0c3b@gmail.com> (raw)
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
prev parent reply other threads:[~2023-04-10 13:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-01 20:50 Add a way to disable «git clean» per repo Guillem Jover
2023-04-03 17:36 ` Junio C Hamano
2023-04-09 17:01 ` Guillem Jover
2023-04-10 13:32 ` Thomas Guyot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37127bb2-8fa2-5908-6824-bb9be9bb0c3b@gmail.com \
--to=tguyot@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=guillem@hadrons.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).