threads / patch / 10584

patch, 2 partsWar on whitespace: first, a bit of retreat.

Subject: [PATCH 1/2] War on whitespace: first, a bit of retreat.

## tl;dr

12 messages between Nov 2, 2007 and Nov 14, 2007. Diffs are folded; open one to read it.

replies: 11people: 6as markdown or json

Junio C Hamano· Nov 2, 2007, 07:34 UTC · lore

This introduces core.whitespace configuration variable that lets you specify the definition of "whitespace error".

Currently there are two kinds of whitespace errors defined:
 * trailing-space: trailing whitespaces at the end of the line.
 * space-before-tab: a SP appears immediately before HT in the
   indent part of the line.

You can specify the desired types of errors to be detected by listing their names (unique abbreviations are accepted) separated by comma. By default, these two errors are always detected, as that is the traditional behaviour. You can disable detection of a particular type of error by prefixing a '-' in front of the name of the error, like this:

	[core]
		whitespace = -trailing-space

This patch teaches the code to output colored diff with DIFF_WHITESPACE color to highlight the detected whitespace errors to honor the new configuration.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 cache.h       |    9 +++++++++
 config.c      |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 diff.c        |   13 ++++++++-----
 environment.c |    1 +
 4 files changed, 70 insertions(+), 5 deletions(-)
Show changes to 4 files +70 −5

cache.h, config.c, diff.c, environment.c

diff --git a/cache.h b/cache.h
index bfffa05..a6e5988 100644
--- a/cache.h
+++ b/cache.h
@@ -602,4 +602,13 @@ extern int diff_auto_refresh_index;
 /* match-trees.c */
 void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
 
+/*
+ * whitespace rules.
+ * used by both diff and apply
+ */
+#define WS_TRAILING_SPACE	01
+#define WS_SPACE_BEFORE_TAB	02
+#define WS_DEFAULT_RULE (WS_TRAILING_SPACE|WS_SPACE_BEFORE_TAB)
+extern unsigned whitespace_rule;
+
 #endif /* CACHE_H */
diff --git a/config.c b/config.c
index dc3148d..ffb418c 100644
--- a/config.c
+++ b/config.c
@@ -246,6 +246,53 @@ static unsigned long get_unit_factor(const char *end)
 	die("unknown unit: '%s'", end);
 }
 
+static struct whitespace_rule {
+	const char *rule_name;
+	unsigned rule_bits;
+} whitespace_rule_names[] = {
+	{ "trailing-space", WS_TRAILING_SPACE },
+	{ "space-before-tab", WS_SPACE_BEFORE_TAB },
+};
+
+static unsigned parse_whitespace_rule(const char *string)
+{
+	unsigned rule = WS_DEFAULT_RULE;
+
+	while (string) {
+		int i;
+		size_t len;
+		const char *ep;
+		int negated = 0;
+
+		string = string + strspn(string, ", \t\n\r");
+		ep = strchr(string, ',');
+		if (!ep)
+			len = strlen(string);
+		else
+			len = ep - string;
+
+		if (*string == '-') {
+			negated = 1;
+			string++;
+			len--;
+		}
+		if (!len)
+			break;
+		for (i = 0; i < ARRAY_SIZE(whitespace_rule_names); i++) {
+			if (strncmp(whitespace_rule_names[i].rule_name,
+				    string, len))
+				continue;
+			if (negated)
+				rule &= ~whitespace_rule_names[i].rule_bits;
+			else
+				rule |= whitespace_rule_names[i].rule_bits;
+			break;
+		}
+		string = ep;
+	}
+	return rule;
+}
+
 int git_parse_long(const char *value, long *ret)
 {
 	if (value && *value) {
@@ -431,6 +478,11 @@ int git_default_config(const char *var, const char *value)
 		return 0;
 	}
 
+	if (!strcmp(var, "core.whitespace")) {
+		whitespace_rule = parse_whitespace_rule(value);
+		return 0;
+	}
+
 	/* Add other config variables here and to Documentation/config.txt. */
 	return 0;
 }
diff --git a/diff.c b/diff.c
index a6aaaf7..2112353 100644
--- a/diff.c
+++ b/diff.c
@@ -508,7 +508,8 @@ static void emit_line_with_ws(int nparents,
 	for (i = col0; i < len; i++) {
 		if (line[i] == '\t') {
 			last_tab_in_indent = i;
-			if (0 <= last_space_in_indent)
+			if ((whitespace_rule & WS_SPACE_BEFORE_TAB) &&
+			    0 <= last_space_in_indent)
 				need_highlight_leading_space = 1;
 		}
 		else if (line[i] == ' ')
@@ -540,10 +541,12 @@ static void emit_line_with_ws(int nparents,
 	tail = len - 1;
 	if (line[tail] == '\n' && i < tail)
 		tail--;
-	while (i < tail) {
-		if (!isspace(line[tail]))
-			break;
-		tail--;
+	if (whitespace_rule & WS_TRAILING_SPACE) {
+		while (i < tail) {
+			if (!isspace(line[tail]))
+				break;
+			tail--;
+		}
 	}
 	if ((i < tail && line[tail + 1] != '\n')) {
 		/* This has whitespace between tail+1..len */
diff --git a/environment.c b/environment.c
index b5a6c69..624dd96 100644
--- a/environment.c
+++ b/environment.c
@@ -35,6 +35,7 @@ int pager_in_use;
 int pager_use_color = 1;
 char *editor_program;
 int auto_crlf = 0;	/* 1: both ways, -1: only when adding git objects */
+unsigned whitespace_rule = WS_DEFAULT_RULE;
 
 /* This is set by setup_git_dir_gently() and/or git_default_config() */
 char *git_work_tree_cfg;
-- 
1.5.3.5.1452.ga93d
Junio C Hamano· Nov 2, 2007, 07:38 UTC · re: Junio C Hamano · lore

[PATCH 2/2] git-diff: complain about >=8 consecutive spaces in initial indent

This introduces a new whitespace error type, "indent-with-non-tab". The error is about starting a line with 8 or more SP, instead of indenting it with a HT.

This is not enabled by default, as some projects employ an indenting policy to use only SPs and no HTs.

The kernel folks and git contributors may want to enable this detection with:

	[core]
		whitespace = indent-with-non-tab
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * Obviously, it is too late at night for me to do the same for
   git-apply, but it's Ok as I know there are capable interested
   parties on the list.  Hint, hint...
 cache.h  |    1 +
 config.c |    1 +
 diff.c   |   14 ++++++++++++--
 3 files changed, 14 insertions(+), 2 deletions(-)
Show changes to 3 files +14 −2

cache.h, config.c, diff.c

diff --git a/cache.h b/cache.h
index a6e5988..3f42827 100644
--- a/cache.h
+++ b/cache.h
@@ -608,6 +608,7 @@ void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, i
  */
 #define WS_TRAILING_SPACE	01
 #define WS_SPACE_BEFORE_TAB	02
+#define WS_INDENT_WITH_NON_TAB	04
 #define WS_DEFAULT_RULE (WS_TRAILING_SPACE|WS_SPACE_BEFORE_TAB)
 extern unsigned whitespace_rule;
 
diff --git a/config.c b/config.c
index ffb418c..d5b9766 100644
--- a/config.c
+++ b/config.c
@@ -252,6 +252,7 @@ static struct whitespace_rule {
 } whitespace_rule_names[] = {
 	{ "trailing-space", WS_TRAILING_SPACE },
 	{ "space-before-tab", WS_SPACE_BEFORE_TAB },
+	{ "indent-with-non-tab", WS_INDENT_WITH_NON_TAB },
 };
 
 static unsigned parse_whitespace_rule(const char *string)
diff --git a/diff.c b/diff.c
index 2112353..6bb902f 100644
--- a/diff.c
+++ b/diff.c
@@ -502,8 +502,11 @@ static void emit_line_with_ws(int nparents,
 	int i;
 	int tail = len;
 	int need_highlight_leading_space = 0;
-	/* The line is a newly added line.  Does it have funny leading
-	 * whitespaces?  In indent, SP should never precede a TAB.
+	/*
+	 * The line is a newly added line.  Does it have funny leading
+	 * whitespaces?  In indent, SP should never precede a TAB.  In
+	 * addition, under "indent with non tab" rule, there should not
+	 * be more than 8 consecutive spaces.
 	 */
 	for (i = col0; i < len; i++) {
 		if (line[i] == '\t') {
@@ -517,6 +520,13 @@ static void emit_line_with_ws(int nparents,
 		else
 			break;
 	}
+	if ((whitespace_rule & WS_INDENT_WITH_NON_TAB) &&
+	    0 <= last_space_in_indent &&
+	    last_tab_in_indent < 0 &&
+	    8 <= (i - col0)) {
+		last_tab_in_indent = i;
+		need_highlight_leading_space = 1;
+	}
 	fputs(set, stdout);
 	fwrite(line, col0, 1, stdout);
 	fputs(reset, stdout);
-- 
1.5.3.5.1452.ga93d
Josh Triplett· Nov 13, 2007, 23:37 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/2] git-diff: complain about >=8 consecutive spaces in initial indent

[CCing David Symonds, because the same comment also applies to his patches.]

Junio C Hamano wrote:
Show 12 quoted lines
> This introduces a new whitespace error type, "indent-with-non-tab".
> The error is about starting a line with 8 or more SP, instead of
> indenting it with a HT.
> 
> This is not enabled by default, as some projects employ an
> indenting policy to use only SPs and no HTs.
> 
> The kernel folks and git contributors may want to enable this
> detection with:
> 
> 	[core]
> 		whitespace = indent-with-non-tab

This seems somewhat broken, whether a project uses tabs for indentation or not. Lines can still legitimately start with many spaces. Tab-based indentation should only use tabs to line up with other tabs, not with characters. (Unfortunately most editors get this wrong when indenting with tabs. I use spaces, not because I ideologically oppose tabs, but because I can't get any editor I want to use to do the right thing with tabs.)

My standard test case for this:
fprintf("some very long string",
        arguments);

Type the first line, and press enter. A good editor should indent to the open parenthesis. However, it should not use a tab, because it needs to match up with the length of "fprintf(". All the editors I know of use a tab; they just blindly replace a tab-width worth of spaces with a tab in initial indentation.

That statement would normally appear indented in a function, so the continuation line should have tabs up to the indentation level of the fprintf, and then 8 spaces. An example more likely to appear at the start of the line, where this indent-with-non-tab heuristic would flag it:

#define macro(arg1, arg2) macro_content \
                          more_macro_content
Another example:
some_type function_name(arg1, arg2, argred, argblue,
                        argmore, argless)

Again, the indentation should use spaces if it wants to line up after the open parenthesis, whether the project uses tabs or spaces for indentation.

(Those examples may or may not match all coding styles; some just indent the continuation lines by a fixed number of tabs, and also treat the first line as a continuation line to keep the indentation consistent. Just presenting them as examples.)

- Josh Triplett
Junio C Hamano· Nov 14, 2007, 00:46 UTC · re: Josh Triplett · lore

Re: [PATCH 2/2] git-diff: complain about >=8 consecutive spaces in initial indent

Josh Triplett <josh@freedesktop.org> writes:
Show 8 quoted lines
> My standard test case for this:
>
> fprintf("some very long string",
>         arguments);
>
> Type the first line, and press enter.  A good editor should indent to
> the open parenthesis.  However, it should not use a tab, because it
> needs to match up with the length of "fprintf(".

Sorry, I do not want to go into ideology or be anal, but I have to disagree. Tab width is 8 spaces (in the kernel and git), so "fprintf(" from the beginning of the line and an HT at the beginning of the line have the same width.

Your project may have different conventions. Then you do not have to use that option to check for 8 or more leading spaces.

And honestly, I think responding to that by saying "but somebody can have tab width that is not 8" is irrelevant. Somebody else can even use a non-proportional font to print it, so your 8 spaces and "fprintf(" won't line up ANYWAY.

If you REALLY want to be anal, then the rules to follow would be:

 - Do not assume you know the width of a HT, other than that the
   same number of HT at the beginning of two lines indent to the
   same distance from the left margin, and more of them indent
   deeper;
 - Do not assume the text will be printed in monospace;
which leads to:
 - Indent with the same number of HT from the beginning of
   lines.  Go deeper with one more HT, go shallower with one
   less HT.
 - Start the continuation line with the same number of HT to
   indent but DO NOT BOTHER aligning.  There is no alignment,
   period.

I happen to choose to be less anal, and accept 8 space HT _and_ monospace font. So "complaining at >=8 SP at the beginning" makes perfect sense, so does a corresponding patch to convert such runs of SPs to HTs with "git-apply --whitespace=fix" (which should require an option to be enabled, and the is not here yet) when applying a patch.

David Symonds· Nov 2, 2007, 10:14 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.

On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> This introduces core.whitespace configuration variable that lets
> you specify the definition of "whitespace error".
>
> Currently there are two kinds of whitespace errors defined:
>
>  * trailing-space: trailing whitespaces at the end of the line.
>
>  * space-before-tab: a SP appears immediately before HT in the
>    indent part of the line.
>         [core]
>                 whitespace = -trailing-space

Could I suggest naming the option 'whitespaceError', so it's clearer that it's a negative setting?

Dave.
Andreas Ericsson· Nov 2, 2007, 10:45 UTC · re: David Symonds · lore

Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.

David Symonds wrote:
Show 17 quoted lines
> On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
>> This introduces core.whitespace configuration variable that lets
>> you specify the definition of "whitespace error".
>>
>> Currently there are two kinds of whitespace errors defined:
>>
>>  * trailing-space: trailing whitespaces at the end of the line.
>>
>>  * space-before-tab: a SP appears immediately before HT in the
>>    indent part of the line.
> 
>>         [core]
>>                 whitespace = -trailing-space
> 
> Could I suggest naming the option 'whitespaceError', so it's clearer
> that it's a negative setting?
> 

Which would also open the window for "WhitespaceWarning" and "WhitespaceAutofix" later on, using the same semantics. Personally, I'd like to get warnings for non-tab-indent^H^H^H indent-with-non-tab (rename that option, perhaps?), autofix for trailing-whitespace and errors for space-before-tab, with command-line switch to override config settings.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
David Symonds· Nov 2, 2007, 11:50 UTC · re: Andreas Ericsson · lore

Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.

On 11/2/07, Andreas Ericsson <ae@op5.se> wrote:
Show 21 quoted lines
> David Symonds wrote:
> > On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> This introduces core.whitespace configuration variable that lets
> >> you specify the definition of "whitespace error".
> >>
> >> Currently there are two kinds of whitespace errors defined:
> >>
> >>  * trailing-space: trailing whitespaces at the end of the line.
> >>
> >>  * space-before-tab: a SP appears immediately before HT in the
> >>    indent part of the line.
> >
> >>         [core]
> >>                 whitespace = -trailing-space
> >
> > Could I suggest naming the option 'whitespaceError', so it's clearer
> > that it's a negative setting?
> >
>
> Which would also open the window for "WhitespaceWarning" and "WhitespaceAutofix"
> later on, using the same semantics.
Maybe cut straight to the chase:
[core]
        whitespace.trailing = error
        whitespace.space-before-tab = error
        whitespace.8-spaces = warn

There'd be at least "error", "warn"; "okay" and "autofix" would be other sensible values. I'm willing to help code this up if this sounds good.

Dave.
Jakub Narebski· Nov 2, 2007, 12:25 UTC · re: David Symonds · lore

Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.

David Symonds wrote:
Show 32 quoted lines
> On 11/2/07, Andreas Ericsson <ae@op5.se> wrote:
>> David Symonds wrote:
>>> On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
>>>> This introduces core.whitespace configuration variable that lets
>>>> you specify the definition of "whitespace error".
>>>>
>>>> Currently there are two kinds of whitespace errors defined:
>>>>
>>>>  * trailing-space: trailing whitespaces at the end of the line.
>>>>
>>>>  * space-before-tab: a SP appears immediately before HT in the
>>>>    indent part of the line.
>>>
>>>>         [core]
>>>>                 whitespace = -trailing-space
>>>
>>> Could I suggest naming the option 'whitespaceError', so it's clearer
>>> that it's a negative setting?
>>
>> Which would also open the window for "WhitespaceWarning" and "WhitespaceAutofix"
>> later on, using the same semantics.
> 
> Maybe cut straight to the chase:
> 
> [core]
>         whitespace.trailing = error
>         whitespace.space-before-tab = error
>         whitespace.8-spaces = warn
> 
> There'd be at least "error", "warn"; "okay" and "autofix" would be
> other sensible values. I'm willing to help code this up if this sounds
> good.
Nice idea, but the syntax is
[core "whitespace"]
        trailing = error
        space-before-tab = error
        indent-with-space = warn
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
David Symonds· Nov 2, 2007, 12:53 UTC · re: Jakub Narebski · lore

Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.

On 11/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
Show 6 quoted lines
> Nice idea, but the syntax is
>
> [core "whitespace"]
>         trailing = error
>         space-before-tab = error
>         indent-with-space = warn
Whoops, of course. My brain is a bit muddled tonight.
Dave.
David Symonds· Nov 2, 2007, 13:26 UTC · re: David Symonds · lore

Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.

On 11/2/07, David Symonds <dsymonds@gmail.com> wrote:
Show 9 quoted lines
> On 11/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > Nice idea, but the syntax is
> >
> > [core "whitespace"]
> >         trailing = error
> >         space-before-tab = error
> >         indent-with-space = warn
>
> Whoops, of course. My brain is a bit muddled tonight.

Okay, I've put my money where my mouth is, and coded up an equivalent to Junio's patch from the start of this thread. I'll send it through in a couple of minutes.

Dave.
J. Bruce Fields· Nov 2, 2007, 17:45 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.

On Fri, Nov 02, 2007 at 12:34:05AM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> This introduces core.whitespace configuration variable that lets
> you specify the definition of "whitespace error".
> 
> Currently there are two kinds of whitespace errors defined:
> 
>  * trailing-space: trailing whitespaces at the end of the line.
> 
>  * space-before-tab: a SP appears immediately before HT in the
>    indent part of the line.

The whitespace policy varies based on the project (and in some cases, based on the file within that project). It shouldn't vary from user to user or repo to repo. So the configuration variable mechanism seems a poor match. Would it be possible to use something like gitattributes instead? Then the whitespace policy would be associated with the project itself, would automatically be propagated on clone, etc.

Thanks for working on this.
--b.
Show 161 quoted lines
> 
> You can specify the desired types of errors to be detected by
> listing their names (unique abbreviations are accepted)
> separated by comma.  By default, these two errors are always
> detected, as that is the traditional behaviour.  You can disable
> detection of a particular type of error by prefixing a '-' in
> front of the name of the error, like this:
> 
> 	[core]
> 		whitespace = -trailing-space
> 
> This patch teaches the code to output colored diff with
> DIFF_WHITESPACE color to highlight the detected whitespace
> errors to honor the new configuration.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  cache.h       |    9 +++++++++
>  config.c      |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  diff.c        |   13 ++++++++-----
>  environment.c |    1 +
>  4 files changed, 70 insertions(+), 5 deletions(-)
> 
> diff --git a/cache.h b/cache.h
> index bfffa05..a6e5988 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -602,4 +602,13 @@ extern int diff_auto_refresh_index;
>  /* match-trees.c */
>  void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
>  
> +/*
> + * whitespace rules.
> + * used by both diff and apply
> + */
> +#define WS_TRAILING_SPACE	01
> +#define WS_SPACE_BEFORE_TAB	02
> +#define WS_DEFAULT_RULE (WS_TRAILING_SPACE|WS_SPACE_BEFORE_TAB)
> +extern unsigned whitespace_rule;
> +
>  #endif /* CACHE_H */
> diff --git a/config.c b/config.c
> index dc3148d..ffb418c 100644
> --- a/config.c
> +++ b/config.c
> @@ -246,6 +246,53 @@ static unsigned long get_unit_factor(const char *end)
>  	die("unknown unit: '%s'", end);
>  }
>  
> +static struct whitespace_rule {
> +	const char *rule_name;
> +	unsigned rule_bits;
> +} whitespace_rule_names[] = {
> +	{ "trailing-space", WS_TRAILING_SPACE },
> +	{ "space-before-tab", WS_SPACE_BEFORE_TAB },
> +};
> +
> +static unsigned parse_whitespace_rule(const char *string)
> +{
> +	unsigned rule = WS_DEFAULT_RULE;
> +
> +	while (string) {
> +		int i;
> +		size_t len;
> +		const char *ep;
> +		int negated = 0;
> +
> +		string = string + strspn(string, ", \t\n\r");
> +		ep = strchr(string, ',');
> +		if (!ep)
> +			len = strlen(string);
> +		else
> +			len = ep - string;
> +
> +		if (*string == '-') {
> +			negated = 1;
> +			string++;
> +			len--;
> +		}
> +		if (!len)
> +			break;
> +		for (i = 0; i < ARRAY_SIZE(whitespace_rule_names); i++) {
> +			if (strncmp(whitespace_rule_names[i].rule_name,
> +				    string, len))
> +				continue;
> +			if (negated)
> +				rule &= ~whitespace_rule_names[i].rule_bits;
> +			else
> +				rule |= whitespace_rule_names[i].rule_bits;
> +			break;
> +		}
> +		string = ep;
> +	}
> +	return rule;
> +}
> +
>  int git_parse_long(const char *value, long *ret)
>  {
>  	if (value && *value) {
> @@ -431,6 +478,11 @@ int git_default_config(const char *var, const char *value)
>  		return 0;
>  	}
>  
> +	if (!strcmp(var, "core.whitespace")) {
> +		whitespace_rule = parse_whitespace_rule(value);
> +		return 0;
> +	}
> +
>  	/* Add other config variables here and to Documentation/config.txt. */
>  	return 0;
>  }
> diff --git a/diff.c b/diff.c
> index a6aaaf7..2112353 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -508,7 +508,8 @@ static void emit_line_with_ws(int nparents,
>  	for (i = col0; i < len; i++) {
>  		if (line[i] == '\t') {
>  			last_tab_in_indent = i;
> -			if (0 <= last_space_in_indent)
> +			if ((whitespace_rule & WS_SPACE_BEFORE_TAB) &&
> +			    0 <= last_space_in_indent)
>  				need_highlight_leading_space = 1;
>  		}
>  		else if (line[i] == ' ')
> @@ -540,10 +541,12 @@ static void emit_line_with_ws(int nparents,
>  	tail = len - 1;
>  	if (line[tail] == '\n' && i < tail)
>  		tail--;
> -	while (i < tail) {
> -		if (!isspace(line[tail]))
> -			break;
> -		tail--;
> +	if (whitespace_rule & WS_TRAILING_SPACE) {
> +		while (i < tail) {
> +			if (!isspace(line[tail]))
> +				break;
> +			tail--;
> +		}
>  	}
>  	if ((i < tail && line[tail + 1] != '\n')) {
>  		/* This has whitespace between tail+1..len */
> diff --git a/environment.c b/environment.c
> index b5a6c69..624dd96 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -35,6 +35,7 @@ int pager_in_use;
>  int pager_use_color = 1;
>  char *editor_program;
>  int auto_crlf = 0;	/* 1: both ways, -1: only when adding git objects */
> +unsigned whitespace_rule = WS_DEFAULT_RULE;
>  
>  /* This is set by setup_git_dir_gently() and/or git_default_config() */
>  char *git_work_tree_cfg;
> -- 
> 1.5.3.5.1452.ga93d
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Junio C Hamano· Nov 3, 2007, 02:45 UTC · re: J. Bruce Fields · lore

Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.

"J. Bruce Fields" <bfields@fieldses.org> writes:
Show 6 quoted lines
> The whitespace policy varies based on the project (and in some cases,
> based on the file within that project).  It shouldn't vary from user to
> user or repo to repo.  So the configuration variable mechanism seems a
> poor match.  Would it be possible to use something like gitattributes
> instead?  Then the whitespace policy would be associated with the
> project itself, would automatically be propagated on clone, etc.

The use of gitattributes certainly sounds like a good way to go. A project like git may say "HT indent for C sources, SP only for Python parts".

Having said that, I've added a few tests and merged the result to 'next' already. We can improve it to use attributes instead while on 'next'.

And the git-apply side needs a matching adjustment.

← back to recent threads