Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

Junio C Hamano [EMAIL PROTECTED] wrote: Johannes Schindelin [EMAIL PROTECTED] writes: True. My bad old habit. An elegant method to do that: case --some-long-option in $1*) ..; esac You are almost correct, but you need to realize that I generate that long case

Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

Hi, On Tue, 9 Aug 2005, Horst von Brand wrote: Isn't it easier to just use getopt(1)? Only if GNU getopt is available. On Mac OS X, only the BSD version is installed by default, which does not handle long options at all. Please stop! I'm dizzy already! :-) Ciao, Dscho - To unsubscribe

Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

Ryan Anderson [EMAIL PROTECTED] writes: I haven't really given a lot of thought to this yet, but I was thinking of something along these lines: Rename tools/ to mail-tools/, push git-send-email-script into that. Create a porcelain directory for things like git-bisect-script Create a core

Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

Hi, On Tue, 9 Aug 2005, Junio C Hamano wrote: Johannes Schindelin [EMAIL PROTECTED] writes: - I don't like the GNU way to abbreviate long options too much... True. My bad old habit. An elegant method to do that: case --some-long-option in $1*) ..; esac Ciao, Dscho - To unsubscribe

Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

Johannes Schindelin [EMAIL PROTECTED] writes: True. My bad old habit. An elegant method to do that: case --some-long-option in $1*) ..; esac You are almost correct, but you need to realize that I generate that long case -s|--s|--so|--som|... chain using a script that takes all potential

Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

Junio C Hamano [EMAIL PROTECTED] writes: - Multiple -m options was actually a feature of my version of the patch. Ah, OK. I said OK and thought about it again. While thinking about what is the right inter-message-piece separator for multiple -m parameters (you use \n), I got a headache. I

Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

Pavel Roskin [EMAIL PROTECTED] writes: Quoting GNU Coding Standards (info standards): If there are C compiler options that _must_ be used for proper compilation of certain files, do not include them in `CFLAGS'. Users expect to be able to specify `CFLAGS' freely themselves. Quoting

Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

On Mon, Aug 08, 2005 at 01:53:24PM -0700, Junio C Hamano wrote: I do want to revisit Makefile issues after 0.99.4, along with the changes Pasky sent several days ago. Please remind me about them after Wednesday. We should discuss (or just do) a reorganization of how we lay out the source

Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

Hi, On Mon, 8 Aug 2005, Ryan Anderson wrote: [...] We should discuss (or just do) a reorganization of how we lay out the source tree. [...] I, for one, like the layout. There are not yet enough files to merit a hierarchy, and what's more: I can add the source-directory to my PATH and be

[PATCH] Making CFLAGS compilant with GNU Coding Standards

Hello! Quoting GNU Coding Standards (info standards): If there are C compiler options that _must_ be used for proper compilation of certain files, do not include them in `CFLAGS'. Users expect to be able to specify `CFLAGS' freely themselves. This patch renames COPTS to CFLAGS, because it's