git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

      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).