git/ws.c, branch v1.7.2

whitespace: add tab-in-indent support for --whitespace=fix

2010-04-04T21:21:54Z

If tab-in-indent is set, --whitespace=fix will ensure that any stray tabs in the initial indent are expanded to the correct number of space characters. Signed-off-by: Chris Webb Signed-off-by: Junio C Hamano

whitespace: replumb ws_fix_copy to take a strbuf dst instead of char dst

2010-04-04T21:21:54Z

To implement --whitespace=fix for tab-in-indent, we have to allow for the possibility that whitespace can increase in size when it is fixed, expanding tabs to to multiple spaces in the initial indent. Signed-off-by: Chris Webb Signed-off-by: Junio C Hamano

whitespace: add tab-in-indent error class

2010-04-03T04:08:04Z

Some projects and languages use coding style where no tab character is used to indent the lines. This only adds support and documentation for "apply --whitespace=warn" and "diff --check"; later patches add "apply --whitespace=fix" and tests. Signed-off-by: Chris Webb Signed-off-by: Junio C Hamano

whitespace: we cannot "catch all errors known to git" anymore

2010-04-03T04:07:44Z

Traditionally, "*.txt whitespace" in .gitattributes file has been an instruction to catch _all_ classes of whitespace errors known to git. This has to change, however, in order to introduce "tab-in-indent" which is inherently incompatible with "indent-with-non-tab". As we do not want to break configuration of existing users, add a mechanism to allow marking selected rules to be excluded from "all rules known to git". Signed-off-by: Chris Webb Signed-off-by: Junio C Hamano

git_attr(): fix function signature

2010-01-17T04:39:59Z

The function took (name, namelen) as its arguments, but all the public callers wanted to pass a full string. Demote the counted-string interface to an internal API status, and allow public callers to just pass the string to the function. Signed-off-by: Junio C Hamano

Merge branch 'jc/maint-1.6.0-blank-at-eof' (early part) into jc/maint-blank-at-eof

2009-09-15T10:28:08Z

* 'jc/maint-1.6.0-blank-at-eof' (early part): diff --whitespace: fix blank lines at end core.whitespace: split trailing-space into blank-at-{eol,eof} diff --color: color blank-at-eof diff --whitespace=warn/error: fix blank-at-eof check diff --whitespace=warn/error: obey blank-at-eof diff.c: the builtin_diff() deals with only two-file comparison apply --whitespace: warn blank but not necessarily empty lines at EOF apply --whitespace=warn/error: diagnose blank at EOF apply.c: split check_whitespace() into two apply --whitespace=fix: detect new blank lines at eof correctly apply --whitespace=fix: fix handling of blank lines at the eof

core.whitespace: split trailing-space into blank-at-{eol,eof}

2009-09-06T06:14:31Z

People who configured trailing-space depended on it to catch both extra white space at the end of line, and extra blank lines at the end of file. Earlier attempt to introduce only blank-at-eof gave them an escape hatch to keep the old behaviour, but it is a regression until they explicitly specify the new error class. This introduces a blank-at-eol that only catches extra white space at the end of line, and makes the traditional trailing-space a convenient synonym to catch both blank-at-eol and blank-at-eof. This way, people who used trailing-space continue to catch both classes of errors. Signed-off-by: Junio C Hamano

apply --whitespace=warn/error: diagnose blank at EOF

2009-09-04T18:50:26Z

"git apply" strips new blank lines at EOF under --whitespace=fix option, but neigher --whitespace=warn nor --whitespace=error paid any attention to these errors. Introduce a new whitespace error class, blank-at-eof, to make the whitespace error handling more consistent. The patch adds a new "linenr" field to the struct fragment in order to record which line the hunk started in the input file, but this is needed solely for reporting purposes. The detection of this class of whitespace errors cannot be done while parsing a patch like we do for all the other classes of whitespace errors. It instead has to wait until we find where to apply the hunk, but at that point, we do not have an access to the original line number in the input file anymore, hence the new field. Depending on your point of view, this may be a bugfix that makes warn and error in line with fix. Or you could call it a new feature. The line between them is somewhat fuzzy in this case. Strictly speaking, triggering more errors than before is a change in behaviour that is not backward compatible, even though the reason for the change is because the code was not checking for an error that it should have. People who do not want added blank lines at EOF to trigger an error can disable the new error class. Signed-off-by: Junio C Hamano

Fix severe breakage in "git-apply --whitespace=fix"

2009-07-25T08:29:20Z

735c674 (Trailing whitespace and no newline fix, 2009-07-22) completely broke --whitespace=fix, causing it to lose all the empty lines in a patch. Signed-off-by: Junio C Hamano

Trailing whitespace and no newline fix

2009-07-23T01:54:55Z

If a patch adds a new line to the end of a file and this line ends with one trailing whitespace character and has no newline, then '--whitespace=fix' currently does not remove that trailing whitespace. This patch fixes this by removing the check for trailing whitespace at the end of the line at a hardcoded offset which does not take the eventual absence of newline into account. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano