All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH] Add git-clean command
Date: Tue, 04 Apr 2006 11:52:07 -0400	[thread overview]
Message-ID: <1144165927.30675.32.camel@dv> (raw)
In-Reply-To: <20060404105818.GA17326@mars.ravnborg.org>

On Tue, 2006-04-04 at 12:58 +0200, Sam Ravnborg wrote:
> On Mon, Apr 03, 2006 at 05:06:36PM -0700, Junio C Hamano wrote:
> > 
> > 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?

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.

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

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

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

I'll think about the later.

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

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

-- 
Regards,
Pavel Roskin

  reply	other threads:[~2006-04-04 15:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-03 22:18 [PATCH] Add git-clean command Pavel Roskin
2006-04-04  0:06 ` Junio C Hamano
2006-04-04 10:58   ` Sam Ravnborg
2006-04-04 15:52     ` Pavel Roskin [this message]
2006-04-05 16:02       ` unchecked uses of strdup Jim Meyering
2006-04-06 14:11         ` Alex Riesen
2006-04-05  6:00   ` [PATCH] Add git-clean command Pavel Roskin
2006-04-04  8:20 ` Martin Waitz
2006-04-04  9:08   ` Junio C Hamano
2006-04-04  9:17   ` Alex Riesen
2006-04-04 15:32     ` Pavel Roskin
  -- strict thread matches above, loose matches on Subject: below --
2006-04-05  6:00 Pavel Roskin
2006-04-05  6:25 ` Jakub Narebski
2006-04-03 21: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=1144165927.30675.32.camel@dv \
    --to=proski@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=sam@ravnborg.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.