patchAdd git-clean command

This command removes untracked files from the working tree. This implementation is based on cg-clean with some simplifications. The documentation is included.

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

 .gitignore                  |    1 +
 Documentation/git-clean.txt |   50 +++++++++++++++++++++++++++++++
 Makefile                    |    2 +
 git-clean.sh                |   70 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 122 insertions(+), 1 deletions(-)

Pavel Roskin <proski@gnu.org> writes:

I am not opposed to the command in the sense that I do not want to forbid people from doing what they want to do, but on the other hand I do not see why people (apparently many people) want to have something like this. Are their "make clean" broken?

Having said that, just some nitpicks.

I appreciate the attention to the detail; very nice to have a .gitignore entry along with addition of a command.

	for arg
        do
        	...

	case "$arg" in -d)...

The $noexclude case passes two empty strings to git-ls-files, which may happen to be harmless with the current implementation, but does not feel quite right.

Maybe better to read ls-files -z to be really pathname safe, I dunno.

I am not quite sure this chmod -R is a good idea. If we are trying really hard would we need to also make sure we can rmdir the "$file" by chmod'ing its parent directory? But once we start doing that where would we stop?

On Mon, Apr 03, 2006 at 05:06:36PM -0700, Junio C Hamano wrote:

No reason to waste time on make clean. git ls-files -o | xargs rm Does the same job nicely.

Other typical usecases for me: Remove temporaries that I created while trying out stuff. Often I have a bunch of files named 'x', 'xx', 'fisk' etc. around for no use. An easy way to remove these without breaking my 'allmodconfig' build is nice. It anyway > 1 hour to build and I like to get rid of the untracked stuff in an easy way.

So use cases goes like this:
- Remove everything not tracked by git (including .gitignore files)
- Remove everything except tracked by git or ignored
- Remove ignored files (replacement of make clean) (seldom)

Above should work both from top-level dir and in subdirectories.

That is my minimal expectations to git clean. What Pavel came up with cover everything except the make clean replacement part.

	Sam

On Tue, 2006-04-04 at 12:58 +0200, Sam Ravnborg wrote:

Normally it is not, but if it is, they want to know it. If git-clean remove something after "make clean" then maybe the later is incomplete.

To put it another way, if I make changes and share them with others, I want to make sure that my changes will work for them. If the mechanism for sharing my changes is make-based, I rely on make to check them. In projects using Automake it's called "make distcheck". If I'm sharing my changes as a git patch, I want a git-based verification that the project still builds from scratch.

Also, the files cleaned by "make clean" are normally build products. Things that you _really_ don't want to be in the source tree at the release time are other files, such as backup files with changes that you decided to back out, sources that you may not share, firmware that cost your company $50000 and so on. "make clean" won't remove them.

This would remove ignored files.  It's not always what I want.

I'll think about the later.

Exactly. The "make clean" replacement is actually the one I didn't implement.

There are pretty many uses of strdup in git's sources. Here's one that can cause trouble if it ever returns NULL:

    [from fsck-objects.c]
    static int fsck_head_link(void)
    {
            unsigned char sha1[20];
            const char *git_HEAD = strdup(git_path("HEAD"));
            const char *git_refs_heads_master = resolve_ref(git_HEAD, sha1, 1);

The problem is that resolve_ref does an unconditional `stat' on the parameter corresponding to the maybe-NULL git_HEAD.

One solution is to change such uses of strdup to uses of xstrdup.

On 4/5/06, Jim Meyering <jim@meyering.net> wrote:

That's actually alright (aside a nice core file). Worse are the cases where a NULL would cause some "normal" behaviour, e.g. arguments, which have a meaning for NULL value.

On Mon, 2006-04-03 at 17:06 -0700, Junio C Hamano wrote:

I checked other git shell scripts and copied the "while" construct from one of them - if it's good for other commands, it's good for git-clean.

Good catch. This is needed since $GIT_DIR can contain spaces. I believe ${excl2:+"$excl2"} would do the trick.

I think "xargs -0" has its own problems (argument length limitations), and the other solution is to use perl. While at that, I'd rather rewrite the whole script in Perl, or maybe in even C.

I think this should eventually happen to all git scripts, but I have no intention to do it right now unless you really want me to.

OK, I was undecided on that.  I'm dropping this option.

hoi :)

as ignored files are generally generated files, doesn't it make sense to clean up the "ignored" files, and leave other untracked files alone? That way you don't loose files which you forgot to add to git.

What is the use case of cleaning up all untracked files without also cleaning ignored files?

Martin Waitz <tali@admingilde.org> writes:

Sounds like a sane suggestion, but my previous comment about "make clean" broken for people who want this "git clean" feature applies here as well.

One justification I can think of for "git clean" without -x flag is to make a clean tree that has only the source and build products, removing editor backup files, throwaway test output files and friends, but as you pointed out, this risks losing newly created source files that you forgot to add, so I would need a bit of convincing before I use such a command myself.

Compared to that, removing only ignored files sounds like a much safer operation -- they are explicitly listed as expendable, so it is a lot less likely to lose anything important. But again, that is what "make clean" is there for...

On 4/4/06, Martin Waitz <tali@admingilde.org> wrote:

Thinks of git's .gitignore: it has config.mak in it. Are you sure you want "clean" your build customizations?

On Tue, 2006-04-04 at 11:17 +0200, Alex Riesen wrote:

In may case, I normally want to remove copies of the sources. For example, I take foo.c, make a clean copy of it, then I change and test it. If if doesn't work and I want to try another approach, I copy it to foo.c-bad or foo.c-approach1. I also make diffs between files to see what exactly I changed. I may also create files for output, valgrind logs and so on.

At some point, I'm satisfied with foo.c, so I commit it. Then I want to remove copies, diffs and other stuff. Yet I don't want to rebuild everything.

It's very rare that I add a new file, and I always remember to add it to the version control. But I'll consider adding an option to only remove ignored files.