The hunk header pattern 'cpp' is intended for C and C++ source code, but
it is actually not particularly useful for the latter, and even misses
some use-cases for the former.
The parts of the pattern have the following flaws:
- The first part matches an identifier followed immediately by a colon
and arbitrary text and is intended to reject goto labels and C++
access specifiers (public, private, protected). But this pattern also
rejects C++ constructs, which look like this:
MyClass::MyClass()
MyClass::~MyClass()
MyClass::Item MyClass::Find(...
- The second part matches an identifier followed by a list of qualified
names (i.e. identifiers separated by the C++ scope operator '::')
separated by space or '*' followed by an opening parenthesis (with
space between the tokens). It matches function declarations like
struct item* get_head(...
int Outer::Inner::Func(...
Since the pattern requires at least two identifiers, GNU-style
function definitions are ignored:
void
func(...
Moreover, since the pattern does not allow punctuation other than '*',
the following C++ constructs are not recognized:
. template definitions:
template<class T> int func(T arg)
. functions returning references:
const string& get_message()
. functions returning templated types:
vector<int> foo()
. operator definitions:
Value operator+(Value l, Value r)
- The third part of the pattern finally matches compound definitions.
But it forgets about unions and namespaces, and also skips single-line
definitions
struct random_iterator_tag {};
because no semicolon can occur on the line.
Change the first pattern to require a colon at the end of the line
(except for trailing space and comments), so that it does not reject
constructor or destructor definitions.
Notice that all interesting anchor points begin with an identifier or
keyword. But since there is a large variety of syntactical constructs
after the first "word", the simplest is to require only this word and
accept everything else. Therefore, this boils down to a line that begins
with a letter or underscore (optionally preceded by the C++ scope
operator '::' to accept functions returning a type anchored at the
global namespace). Replace the second and third part by a single pattern
that picks such a line.
This has the following desirable consequence:
- All constructs mentioned above are recognized.
and the following likely desirable consequences:
- Definitions of global variables and typedefs are recognized:
int num_entries = 0;
extern const char* help_text;
typedef basic_string<wchar_t> wstring;
- Commonly used marco-ized boilerplate code is recognized:
BEGIN_MESSAGE_MAP(CCanvas,CWnd)
Q_DECLARE_METATYPE(MyStruct)
PATTERNS("tex",...)
(The last one is from this very patch.)
but also the following possibly undesirable consequence:
- When a label is not on a line by itself (except for a comment) it is
no longer rejected, but can appear as a hunk header if it occurs at
the beginning of a line:
next:;
IMO, the benefits of the change outweigh the (possible) regressions by a
large margin.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of the tests show C++ code, but there is also a union definition and
a GNU style function definition that are not recognized.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A later patch changes the built-in cpp pattern. These test cases
demonstrate aspects of the pattern that we do not want to change.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All test cases that need a file with specific text patterns have been
converted to utilize texts in the t4018/ directory. The remaining tests
in the test script deal only with the validity of the regular
expressions. These tests do not depend on the contents of files that
'git diff' is invoked on. Remove the largish here-document and use only
tiny files.
While we are touching these tests, convert grep to test_i18ngrep as the
texts checked for may undergo translation in the future.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For the test case "matches to end of line", extend the pattern by a few
wildcards so that the pattern captures the "RIGHT" token, which is needed
for verification, without mentioning it in the pattern.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is one subtlety: The old test case 'perl pattern gets full line of
POD header' does not have its own new test case, but the feature is
tested nevertheless by placing the RIGHT tag at the end of the expected
hunk header in t4018/perl-skip-sub-in-pod.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add an infrastructure that simplifies adding new tests of the hunk
header regular expressions.
To add new tests, a file with the syntax to test can be dropped in the
directory t4018. The README file explains how a test file must contain;
the README itself tests the default behavior.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not split constants such as 123U, 456ll, 789UL at the first U or
second L.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The character sequences ->* and .* are valid C++ operators. Keep them
together in --word-diff mode.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git merge-base --octopus" used to leave cleaning up suboptimal
result to the caller, but now it does the clean-up itself.
* bm/merge-base-octopus-dedup:
merge-base --octopus: reduce the result from get_octopus_merge_bases()
merge-base: separate "--independent" codepath into its own helper
"git log --left-right A...B" lost the "leftness" of commits
reachable from A when A is a tag as a side effect of a recent
bugfix. This is a regression in 1.8.4.x series.
* jc/revision-range-unpeel:
revision: propagate flag bits from tags to pointees
revision: mark contents of an uninteresting tree uninteresting
"git clone" would fail to clone from a repository that has a ref
directly under "refs/", e.g. "refs/stash", because different
validation paths do different things on such a refname. Loosen the
client side's validation to allow such a ref.
* jk/allow-fetch-onelevel-refname:
fetch-pack: do not filter out one-level refs
A handful of bugs around interpreting $branch@{upstream} notation
and its lookalike, when $branch part has interesting characters,
e.g. "@", and ":", have been fixed.
* jk/interpret-branch-name-fix:
interpret_branch_name: find all possible @-marks
interpret_branch_name: avoid @{upstream} past colon
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name: rename "cp" variable to "at"
interpret_branch_name: factor out upstream handling
A recent update to "git send-email" broke platforms where
/etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path
(e.g. Fedora rawhide).
* rk/send-email-ssl-cert:
send-email: /etc/ssl/certs/ directory may not be usable as ca_path
"git repack --max-pack-size=8g" stopped being parsed correctly when
the command was reimplemented in C.
* sb/repack-in-c:
repack: propagate pack-objects options as strings
repack: make parsed string options const-correct
repack: fix typo in max-pack-size option
The pathspec matching code, while comparing two trees (e.g. "git
diff A B -- path1 path2") was too aggressive and failed to match
some paths when multiple pathspecs were involved.
* as/tree-walk-fix-aggressive-short-cut:
tree_entry_interesting: match against all pathspecs
The recent translation was giving the idea that all commits
based on a graft were meant to be hidden. Make it clear that
it is the graft commit itself.
Reported-by: David Kastrup <dak@gnu.org>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
We wanted to call the upcoming release "Git 1.9", with its
maintenance track being "Git 1.9.1", "Git 1.9.2", etc., but various
third-party tools are reported to assume that there are at least
three dewey-decimal components in our version number.
Adjust the plan so that vX.Y.0 are feature releases while vX.Y.Z
(Z > 0) are maintenance releases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation to "git pull" hinted there is an "-m" option
because it incorrectly shared the documentation with "git merge".
* jc/maint-pull-docfix:
Documentation: "git pull" does not have the "-m" option
Documentation: exclude irrelevant options from "git pull"
The implementation of 'git stash $cmd "stash@{...}"' did not quote
the stash argument properly and left it split at IFS whitespace.
* ow/stash-with-ifs:
stash: handle specifying stashes with $IFS
There is no reason to have a hardcoded upper limit of the number of
parents for an octopus merge, created via the graft mechanism, but
there was.
* js/lift-parent-count-limit:
Remove the line length limit for graft files
"git add -A" (no other arguments) in a totally empty working tree
used to emit an error.
* nd/add-empty-fix:
add: don't complain when adding empty project root
When we figure out how many file descriptors to allocate for
keeping packfiles open, a system with non-working getrlimit() could
cause us to die(), but because we make this call only to get a
rough estimate of how many is available and we do not even attempt
to use up all file descriptors available ourselves, it is nicer to
fall back to a reasonable low value rather than dying.
* jh/rlimit-nofile-fallback:
get_max_fd_limit(): fall back to OPEN_MAX upon getrlimit/sysconf failure
"git commit -v" appends the patch to the log message before
editing, and then removes the patch when the editor returned
control. However, the patch was not stripped correctly when the
first modified path was a submodule.
* jl/commit-v-strip-marker:
commit -v: strip diffs and submodule shortlogs from the commit message
SSL-related options were not passed correctly to underlying socket
layer in "git send-email".
* tr/send-email-ssl:
send-email: set SSL options through IO::Socket::SSL::set_client_defaults
send-email: --smtp-ssl-cert-path takes an argument
send-email: pass Debug to Net::SMTP::SSL::new
Remote repository URL expressed in scp-style host:path notation are
parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks
to connect to user's home directory on host at address ::1.
* tb/clone-ssh-with-colon-for-port:
git_connect(): use common return point
connect.c: refactor url parsing
git_connect(): refactor the port handling for ssh
git fetch: support host:/~repo
t5500: add test cases for diag-url
git fetch-pack: add --diag-url
git_connect: factor out discovery of the protocol and its parts
git_connect: remove artificial limit of a remote command
t5601: add tests for ssh
t5601: remove clear_ssh, refactor setup_ssh_wrapper
"git fetch --depth=0" was a no-op, and was silently ignored.
Diagnose it as an error.
* nd/transport-positive-depth-only:
clone,fetch: catch non positive --depth option value
When a repo was fully repacked, and is repacked again, we may run
into the situation that "new" packfiles have the same name as
already existing ones (traditionally packfiles have been named after
the list of names of objects in them, so repacking all the objects
in a single pack would have produced a packfile with the same name).
The logic is to rename the existing ones into filename like
"old-XXX", create the new ones and then remove the "old-" ones.
When something went wrong in the middle, this sequence is rolled
back by renaming the "old-" files back.
The renaming into "old-" did not work as intended, because
file_exists() was done on "XXX", not "pack-XXX". Also when rolling
back the change, the code tried to rename "old-pack-XXX" but the
saved ones are named "old-XXX", so this couldn't have worked.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- Allow extra space in "is new" and "is separate"
- Fix bug in word regex for numbers
Signed-off-by: Adrian Johnson <ajohnson@redneon.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This goes far back to e84fb2f (branch --contains: default to HEAD -
2008-07-08) where the same parsing code is shared with
builtin/tag.c. git-branch.txt correctly states that <commit> for
--contains is optional while git-tag.txt does not. Correct it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
