Re: [GUILT PATCH 3/4] guilt-select: Select guards to apply when pushing patches

From: Josef Sipek <jsipek@fsl.cs.sunysb.edu>
Date: Jul 30, 2007, 19:34 UTC
Message-ID: <20070730193418.GD17253@filer.fsl.cs.sunysb.edu>
In-Reply-To: <87fy36cr25.fsf@hubert.paunchy.net>

On Mon, Jul 30, 2007 at 12:02:26AM -0700, Eric Lesh wrote:

Show 15 quoted lines

> Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
> 
> [...]
> 
> >> +if [ $# == 0 ]; then
> >> +	if [ -s "$guards_file" ]; then
> >> +		cat "$guards_file"
> >
> > Later on, for the -s option processing, you sort (presumably to have uniq do
> > the right thing), should we sort here too to be consitent?
> >
> 
> The $guards_file isn't really meant to be handed edited, and
> guilt-select itself sorts before it stores them in the guards file.  I could
> sort it again on printing, but don't think it's necessary.

 
Duh. No need to re-sort.

Show 11 quoted lines

> >> +
> >> +case $1 in
> >> +	-n|--none)
> >> +		rm -f "$guards_file"
> >> +		touch "$guards_file"
> >
> > Since guilt-init doesn't create the guards file, I'm thinking that this
> > should be just a rm -f ...
> 
> Should guilt-init create it?  I added $guards_file to guilt(7), so not
> seeing it might freak Documentation-conscious readers out?

I'm thinking that it would be nice to have the file created when the first guard is set, and removed when the last guard is removed. This way, if you don't care about guards, you don't have to ignore the file (if you have your patches dir under version control). This also happens to be the nicer way to transition from pre-guard patch dirs to ones with guards - in a way it's cheating around "upgrading" the repo :)

I'd like this lazy creation to be documented, of course to not confuse the handful that actually read the docs :)

Jeff.

-- 
Linux, n.:
  Generous programmers from around the world all join forces to help
  you shoot yourself in the foot for free.