git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Petr Baudis <pasky@suse.cz>
Cc: git <git@vger.kernel.org>
Subject: Re: New script: cg-clean
Date: Sat, 06 Aug 2005 03:14:03 -0400	[thread overview]
Message-ID: <1123312443.17959.34.camel@dv.roinet.com> (raw)
In-Reply-To: <20050710154618.GF24249@pasky.ji.cz>

Hello, Petr!

Sorry for delay.

On Sun, 2005-07-10 at 17:46 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Jul 09, 2005 at 12:34:44AM CEST, I got a letter
> where Pavel Roskin <proski@gnu.org> told me that...
> > Hello, Petr!
> 
> Hello,
> 
> > Please consider this script for Cogito.
> > 
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
> 
> the script is definitively interesting, but I have couple of notes
> about it first:
> 
> (i) -i sounds wrong for anything but being interactive here ;-) What
> about -A?

I agree that -i could be confusing, but -A would seem to imply "All", so
let it be -x from "exclude".

> (ii) I'm confused - if -a is all of the above, how do I clean _only_
> regular files, and only those not ignored by cg-status?

cg-clean without options.  I'm changing the description to avoid
confusion.

> (iii) Makes it any sense to remove only special files?

I thought it would make sense to have an option to remove them in
addition to regular files, but now I think it's not worth the trouble to
distinguish between them.

> (iv) -r implies being recursive, but it has nothing to do with that
> here.

Renamed to -d.  Other confusing options have been removed.  "-a" is
retired because it's not hard to type "-dx".  Explicit arguments are not
accepted - one can easily use "rm" instead.  That should make cg-clean
much simpler.

> (v) Semantically, I think it's quite close to cg-reset. What about
> making it part of cg-reset instead of a separate command? I tend to be
> careful about command inflation. (That's part of being careful about the
> usability in general.) That's just an idea and possibly a bad one, what
> do you think?

I understand your concern, but cg-reset does other things.  cg-reset
changes the branch.  cg-clean allows to start the build from scratch
without changing the branch.

It's not uncommon for me to revert patches one-by-one looking for the
patch that breaks something.  I could make minor changes e.g for
debugging or to fix breakage in certain revisions.  I would revert such
by cg-clean before going to another revision.  cg-reset would be an
overkill - it would move me to the latest release.

I can imagine that cg-reset would call cg-clean (optionally) to allow
fresh start on the main branch.  The opposite would be wrong.

Here's the simplified cg-clean script.  Note that the "-d" option is not
working with the current version of git of a bug in git-ls-files.  I can
work it around by scanning all directories in bash, but I think it's
easier to fix git (remove "continue" before DT_REG in ls-files.c).

Processing of .gitignore was taken from cg-status, and I don't really
understand it.  But I think it's important to keep that code in sync.
It could later go to cg-Xlib.

Signed-off-by: Pavel Roskin <proski@gnu.org>

#!/usr/bin/env bash
#
# Clean unknown files from the working tree.
# Copyright (c) Pavel Roskin, 2005
#
# Cleans file and directories that are not under version control.
# When run without arguments, files ignored by cg-status and directories
# are not removed.
#
# OPTIONS
# -------
# -d::
#	Also clean directories.
#
# -x::
#	Also clean files ignored by cg-status, such as object files.

USAGE="cg-clean [-d] [-x]"

. ${COGITO_LIB}cg-Xlib

cleanexclude=
cleandir=
while optparse; do
	if optparse -d; then
		cleandir=1
	elif optparse -x; then
		cleanexclude=1
	else
		optfail
	fi
done

# Good candidate for cg-Xlib
# Put exclude options for git-ls-files to EXCLUDE
set_exclude() {
	EXCLUDE=

	stdignores=('*.[ao]' '.*' tags '*~' '#*' ',,merge*')
	for ign in "${stdignores[@]}"; do
		EXCLUDE="$EXCLUDE --exclude=$ign"
	done

	EXCLUDEFILE=$_git/exclude
	if [ -f "$EXCLUDEFILE" ]; then
		EXCLUDE="$EXCLUDE --exclude-from=$EXCLUDEFILE"
	fi

	{
		path="$_git_relpath"
		dir=
		[ -r .gitignore ] && EXCLUDE="$EXCLUDE --exclude-from=.gitignore"
		while [[ "$path" == */* ]]; do
			dir="${dir:-.}/${path%%/*}"
			path="${path#*/}"
			[ -r $dir/.gitignore ] && EXCLUDE="$EXCLUDE --exclude-from=$dir/.gitignore"
		done
	}
}

if [ -z "$cleanexclude" ]; then
	set_exclude
else
	EXCLUDE=
fi	

git-update-cache --refresh > /dev/null

# Need to use temporary file so that changing IFS doesn't affect $EXCLUDE
# expansion.
filelist=$(mktemp -t gitlsfiles.XXXXXX)
git-ls-files --others $EXCLUDE >"$filelist"
save_IFS="$IFS"
IFS=$'\n'
for file in $(cat "$filelist"); do
	IFS="$save_IFS"
	if [ -d "$file" ]; then
		if [ "$cleandir" ]; then
			# Try really hard by changing permissions
			chmod -R 700 "$file"
			rm -rf "$file"
		fi
		return
	fi
	rm -f "$file"
done

rm -f "$filelist"


-- 
Regards,
Pavel Roskin

  reply	other threads:[~2005-08-06  7:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-08 22:34 New script: cg-clean Pavel Roskin
2005-07-08 22:59 ` Wolfgang Denk
2005-07-10 15:46 ` Petr Baudis
2005-08-06  7:14   ` Pavel Roskin [this message]
2005-08-11 23:29     ` Petr Baudis
2005-08-12  0:54       ` Pavel Roskin
2005-08-12  1:08         ` Petr Baudis
2005-08-12  3:59           ` Pavel Roskin

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1123312443.17959.34.camel@dv.roinet.com \
    --to=proski@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    /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.
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 NNTP newsgroup(s).