* [PATCH] Makefile: Change the default compiler from "gcc" to "cc"
From: Ævar Arnfjörð Bjarmason @ 2011-12-20 23:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Linus Torvalds,
Ævar Arnfjörð Bjarmason
Ever since the very first commit to git.git we've been setting CC to
"gcc". Presumably this is behavior that Linus copied from the Linux
Makefile.
However unlike Linux Git is written in ANSI C and supports a multitude
of compilers, including Clang, Sun Studio, xlc etc. On my Linux box
"cc" is a symlink to clang, and on a Solaris box I have access to "cc"
is Sun Studio's CC.
Both of these are perfectly capable of compiling Git, and it's
annoying to have to specify CC=cc on the command-line when compiling
Git when that's the default behavior of most other portable programs.
So change the default to "cc". Users who want to compile with GCC can
still add "CC=gcc" to the make(1) command-line, but those users who
don't have GCC as their "cc" will see expected behavior, and as a
bonus we'll be more likely to smoke out new compilation warnings from
our distributors since they'll me using a more varied set of compilers
by default.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 9470a10..958c6e6 100644
--- a/Makefile
+++ b/Makefile
@@ -336,7 +336,7 @@ pathsep = :
export prefix bindir sharedir sysconfdir gitwebdir localedir
-CC = gcc
+CC = cc
AR = ar
RM = rm -f
DIFF = diff
--
1.7.7.3
^ permalink raw reply related
* [PATCH] builtin/init-db.c: eliminate -Wformat warning on Solaris
From: Ævar Arnfjörð Bjarmason @ 2011-12-20 23:27 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason
On Solaris systems we'd warn about an implicit cast of mode_t when we
printed things out with the %d format. We'd get this warning under GCC
4.6.0 with Solaris headers:
builtin/init-db.c: In function ‘separate_git_dir’:
builtin/init-db.c:354:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘mode_t’ [-Wformat]
We've been doing this ever since v1.7.4.1-296-gb57fb80. Just work
around this by adding an explicit cast.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
builtin/init-db.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index d07554c..0dacb8b 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -351,7 +351,7 @@ static void separate_git_dir(const char *git_dir)
else if (S_ISDIR(st.st_mode))
src = git_link;
else
- die(_("unable to handle file type %d"), st.st_mode);
+ die(_("unable to handle file type %d"), (int)st.st_mode);
if (rename(src, git_dir))
die_errno(_("unable to move %s to %s"), src, git_dir);
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH] Specify a precision for the length of a subject string
From: Nathan Panike @ 2011-12-20 22:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nathan W. Panike, git
In-Reply-To: <87k45qriu2.fsf@thomas.inf.ethz.ch>
On Tue, Dec 20, 2011 at 11:15:01PM +0100, Thomas Rast wrote:
> "Nathan W. Panike" <nathan.panike@gmail.com> writes:
>
> > This is useful when one is working on a system where the pager is lousy.
>
> I'm curious. Are you saying your less does not have -S (or you do not
> even have less), or do you have a reason not to use it?
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
The reason I thought of this initially was that I have a bot reporting commits
at $dayjob in an IRC channel. Since some of my colleagues commit with long
subject lines, I thought of this as a way to control the output of the bot
(e.g., by controlling the bot's input).
Nathan Panike
^ permalink raw reply
* Re: [PATCH] Specify a precision for the length of a subject string
From: Thomas Rast @ 2011-12-20 22:15 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git
In-Reply-To: <20111220220754.GC21353@llunet.cs.wisc.edu>
"Nathan W. Panike" <nathan.panike@gmail.com> writes:
> This is useful when one is working on a system where the pager is lousy.
I'm curious. Are you saying your less does not have -S (or you do not
even have less), or do you have a reason not to use it?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] Specify a precision for the length of a subject string
From: Nathan W. Panike @ 2011-12-20 22:07 UTC (permalink / raw)
To: git
We can specify the precision of a subject string, so that length the subjects
viewed by the user do not grow beyond a bound set by the user, in a pretty
formatted string
This makes it possible to do, e.g.,
$ git log --pretty='%h %s' d165204 -1
d165204 git-p4: fix skipSubmitEdit regression
With this patch, the user can do
$ git log --pretty='%h %30s' d165204 -1
d165204 git-p4: fix skipSubmitEdit reg
This is useful when one is working on a system where the pager is lousy.
---
Since my colleagues tend to write long subject lines, I like to truncate them
so they do not overwhelm my terminal.
builtin/shortlog.c | 2 +-
commit.h | 2 +-
pretty.c | 35 +++++++++++++++++++++++++++--------
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index 37f3193..a5a07a3 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -98,7 +98,7 @@ static void insert_one_record(struct shortlog *log,
}
while (*oneline && isspace(*oneline) && *oneline != '\n')
oneline++;
- format_subject(&subject, oneline, " ");
+ format_subject(&subject, oneline, " ", 0);
buffer = strbuf_detach(&subject, NULL);
if (dot3) {
diff --git a/commit.h b/commit.h
index 3745f12..a95f4ff 100644
--- a/commit.h
+++ b/commit.h
@@ -100,7 +100,7 @@ extern char *reencode_commit_message(const struct commit *commit,
const char **encoding_p);
extern void get_commit_format(const char *arg, struct rev_info *);
extern const char *format_subject(struct strbuf *sb, const char *msg,
- const char *line_separator);
+ const char *line_separator, int max_len);
extern void userformat_find_requirements(const char *fmt, struct userformat_want *w);
extern void format_commit_message(const struct commit *commit,
const char *format, struct strbuf *sb,
diff --git a/pretty.c b/pretty.c
index 230fe1c..3af7a95 100644
--- a/pretty.c
+++ b/pretty.c
@@ -738,24 +738,33 @@ static void format_sanitized_subject(struct strbuf *sb, const char *msg)
}
const char *format_subject(struct strbuf *sb, const char *msg,
- const char *line_separator)
+ const char *line_separator, int max_len)
{
int first = 1;
-
+ int swritten = 0;
for (;;) {
const char *line = msg;
int linelen = get_one_line(line);
-
msg += linelen;
if (!linelen || is_empty_line(line, &linelen))
break;
if (!sb)
continue;
+ if (0 < max_len && max_len < swritten + linelen) {
+ linelen = max_len - swritten;
+ if(linelen <= 0) {
+ linelen = 0;
+ continue;
+ }
+ }
strbuf_grow(sb, linelen + 2);
- if (!first)
+ if (!first) {
strbuf_addstr(sb, line_separator);
+ swritten += strlen(line_separator);
+ }
strbuf_add(sb, line, linelen);
+ swritten += linelen;
first = 0;
}
return msg;
@@ -769,7 +778,7 @@ static void parse_commit_message(struct format_commit_context *c)
msg = skip_empty_lines(msg);
c->subject_off = msg - start;
- msg = format_subject(NULL, msg, NULL);
+ msg = format_subject(NULL, msg, NULL, 0);
msg = skip_empty_lines(msg);
c->body_off = msg - start;
@@ -830,7 +839,17 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
const char *msg = c->message;
struct commit_list *p;
int h1, h2;
+ int subject_max_len = 0,offset=0;
+ while(isdigit(*placeholder)) {
+ subject_max_len *= 10;
+ subject_max_len += *placeholder - '0';
+ ++placeholder;
+ ++offset;
+ }
+ if(offset > 0 && *placeholder != 's')
+ die("invalid --pretty format: "
+ "'%%(digits)' can only be followed by an s");
/* these are independent of the commit */
switch (placeholder[0]) {
case 'C':
@@ -1002,8 +1021,8 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
switch (placeholder[0]) {
case 's': /* subject */
- format_subject(sb, msg + c->subject_off, " ");
- return 1;
+ format_subject(sb, msg + c->subject_off, " ",subject_max_len);
+ return offset + 1;
case 'f': /* sanitized subject */
format_sanitized_subject(sb, msg + c->subject_off);
return 1;
@@ -1189,7 +1208,7 @@ void pp_title_line(const struct pretty_print_context *pp,
strbuf_init(&title, 80);
*msg_p = format_subject(&title, *msg_p,
- pp->preserve_subject ? "\n" : " ");
+ pp->preserve_subject ? "\n" : " ",0);
strbuf_grow(sb, title.len + 1024);
if (pp->subject) {
--
1.7.8.352.g876a6f.dirty
^ permalink raw reply related
* Re: [PATCH v3] git-sh-setup: make require_clean_work_tree part of the interface
From: Junio C Hamano @ 2011-12-20 22:05 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <b121d918166dea3b578b075ac6b794967c4bdcbe.1324415678.git.trast@student.ethz.ch>
Thanks, will queue.
^ permalink raw reply
* [PATCH v3] git-sh-setup: make require_clean_work_tree part of the interface
From: Thomas Rast @ 2011-12-20 21:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vd3bjj78h.fsf@alter.siamese.dyndns.org>
92c62a3 (Porcelain scripts: Rewrite cryptic "needs update" error
message, 2010-10-19) refactored git's own checking to a function in
git-sh-setup. This is a very useful thing for script writers, so
document it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Junio C Hamano writes:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > +require_clean_work_tree <action> [<hint>]::
> > + checks that the working tree associated with the repository
> > + has no uncommitted changes to tracked files. Otherwise it
> > + emits an error message of the form `Cannot <action>:
> > + <reason>. <hint>`, and dies. Example:
>
> Doesn't it also enforce cleanliness on the index, not just the working tree?
Of course. Here's the "and index" update.
BTW neither gitglossary(7) nor git-cherry-pick(1) get this right.
Documentation/git-sh-setup.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index a2f346c..eb08ba6 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -68,6 +68,16 @@ require_work_tree_exists::
cd_to_toplevel, which is impossible to do if there is no
working tree.
+require_clean_work_tree <action> [<hint>]::
+ checks that the working tree and index associated with the
+ repository have no uncommitted changes to tracked files.
+ Otherwise it emits an error message of the form `Cannot
+ <action>: <reason>. <hint>`, and dies. Example:
++
+----------------
+require_clean_work_tree rebase "Please commit or stash them."
+----------------
+
get_author_ident_from_commit::
outputs code for use with eval to set the GIT_AUTHOR_NAME,
GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
--
1.7.8.484.gdad4270
^ permalink raw reply related
* [PATCH] commit: do not lose mergetag header when not amending
From: Junio C Hamano @ 2011-12-20 21:24 UTC (permalink / raw)
To: git
The earlier ed7a42a (commit: teach --amend to carry forward extra headers,
2011-11-08) broke "git merge/pull; edit to fix conflict; git commit"
workflow by forgetting that commit_tree_extended() takes the whole extra
header list.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Will directly queue to 'master'.
builtin/commit.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index fca7ea0..0c64c88 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1484,8 +1484,12 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
exit(1);
}
- if (amend)
+ if (amend) {
extra = read_commit_extra_headers(current_head);
+ } else {
+ struct commit_extra_header **tail = &extra;
+ append_merge_tag_headers(parents, &tail);
+ }
if (commit_tree_extended(sb.buf, active_cache_tree->sha1, parents, sha1,
author_ident.buf, extra)) {
--
1.7.8.376.g7c0c1
^ permalink raw reply related
* Re: [PATCH] t/t2023-checkout-m.sh: fix use of test_must_fail
From: Junio C Hamano @ 2011-12-20 21:23 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git, Pete Harlan
In-Reply-To: <1324413465-25614-1-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Change an invocation of test_must_fail() to be inside a
> test_expect_success() as is our usual pattern. Having it outside
> caused our tests to fail under prove(1) since we wouldn't print a
> newline before TAP output:
>
> CONFLICT (content): Merge conflict in both.txt
> # GETTEXT POISON #ok 2 - -m restores 2-way conflicted+resolved file
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Thanks.
> ---
> t/t2023-checkout-m.sh | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/t/t2023-checkout-m.sh b/t/t2023-checkout-m.sh
> index 1a40ce0..7e18985 100755
> --- a/t/t2023-checkout-m.sh
> +++ b/t/t2023-checkout-m.sh
> @@ -17,7 +17,9 @@ test_expect_success setup '
> test_commit added_in_topic each.txt in_topic
> '
>
> -test_must_fail git merge master
> +test_expect_success 'git merge master' '
> + test_must_fail git merge master
> +'
>
> clean_branchnames () {
> # Remove branch names after conflict lines
^ permalink raw reply
* Re: [PATCH v2] git-sh-setup: make require_clean_work_tree part of the interface
From: Junio C Hamano @ 2011-12-20 20:52 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <23d761193dcf25f36206adc3d392e8578c566cd7.1324412815.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> 92c62a3 (Porcelain scripts: Rewrite cryptic "needs update" error
> message, 2010-10-19) refactored git's own checking to a function in
> git-sh-setup. This is a very useful thing for script writers, so
> document it.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
> Documentation/git-sh-setup.txt | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
> index a2f346c..9a0e574 100644
> --- a/Documentation/git-sh-setup.txt
> +++ b/Documentation/git-sh-setup.txt
> @@ -68,6 +68,16 @@ require_work_tree_exists::
> cd_to_toplevel, which is impossible to do if there is no
> working tree.
>
> +require_clean_work_tree <action> [<hint>]::
> + checks that the working tree associated with the repository
> + has no uncommitted changes to tracked files. Otherwise it
> + emits an error message of the form `Cannot <action>:
> + <reason>. <hint>`, and dies. Example:
Doesn't it also enforce cleanliness on the index, not just the working tree?
> ++
> +----------------
> +require_clean_work_tree rebase "Please commit or stash them."
> +----------------
> +
> get_author_ident_from_commit::
> outputs code for use with eval to set the GIT_AUTHOR_NAME,
> GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
^ permalink raw reply
* [PATCH] t/t2023-checkout-m.sh: fix use of test_must_fail
From: Ævar Arnfjörð Bjarmason @ 2011-12-20 20:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pete Harlan,
Ævar Arnfjörð Bjarmason
In-Reply-To: <4EDF1631.5090906@pcharlan.com>
Change an invocation of test_must_fail() to be inside a
test_expect_success() as is our usual pattern. Having it outside
caused our tests to fail under prove(1) since we wouldn't print a
newline before TAP output:
CONFLICT (content): Merge conflict in both.txt
# GETTEXT POISON #ok 2 - -m restores 2-way conflicted+resolved file
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t2023-checkout-m.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/t/t2023-checkout-m.sh b/t/t2023-checkout-m.sh
index 1a40ce0..7e18985 100755
--- a/t/t2023-checkout-m.sh
+++ b/t/t2023-checkout-m.sh
@@ -17,7 +17,9 @@ test_expect_success setup '
test_commit added_in_topic each.txt in_topic
'
-test_must_fail git merge master
+test_expect_success 'git merge master' '
+ test_must_fail git merge master
+'
clean_branchnames () {
# Remove branch names after conflict lines
--
1.7.7.3
^ permalink raw reply related
* [PATCH v2] git-sh-setup: make require_clean_work_tree part of the interface
From: Thomas Rast @ 2011-12-20 20:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vwr9rjbaq.fsf@alter.siamese.dyndns.org>
92c62a3 (Porcelain scripts: Rewrite cryptic "needs update" error
message, 2010-10-19) refactored git's own checking to a function in
git-sh-setup. This is a very useful thing for script writers, so
document it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-sh-setup.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index a2f346c..9a0e574 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -68,6 +68,16 @@ require_work_tree_exists::
cd_to_toplevel, which is impossible to do if there is no
working tree.
+require_clean_work_tree <action> [<hint>]::
+ checks that the working tree associated with the repository
+ has no uncommitted changes to tracked files. Otherwise it
+ emits an error message of the form `Cannot <action>:
+ <reason>. <hint>`, and dies. Example:
++
+----------------
+require_clean_work_tree rebase "Please commit or stash them."
+----------------
+
get_author_ident_from_commit::
outputs code for use with eval to set the GIT_AUTHOR_NAME,
GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
--
1.7.8.484.gdad4270
^ permalink raw reply related
* Re: [PATCH 2/2] Documentation: make git-sh-setup docs less scary
From: Thomas Rast @ 2011-12-20 20:27 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <CACBZZX5BSfh8S9Kf1Wbi+NPEKpxJNXU8TD8-hkC2o1Mi91Or6A@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Tue, Dec 20, 2011 at 12:09, Thomas Rast <trast@student.ethz.ch> wrote:
>> At least one IRC user was scared away by the introductory "This is not
>> a command the end user would want to run. Ever." to the point of not
>> reading on.
>
> Arguably that's the point isn't it? To not have people who aren't
> maintaining Git itself waste time on reading it.
Junio C Hamano writes:
> You would need to say what that IRC user needed to find out. Depending on
> that, letting the user know that there is no point reading on early and
> not waste his or her time may be a good thing. That was what the paragraph
> was designed for. IOW, it is not to "scare" away, but to allow the users
> to decide if they are intended audiences.
Well, the original question was [*]
<ribasushi> how do I write a batch-test (goes in a script, exit value matters only) to test if the current workdir is clean?
<ribasushi> i.e. nothing staged/unstaged to commit
<shruggar> last I looked, there was no "all in one" method :/
<shruggar> git diff -q && git diff —cached -q, perhaps
<charon> ribasushi: . "$(git --exec-path)/git-sh-setup" ; require_clean_worktree
<shruggar> but I think that's ignoring something
<ribasushi> lack of output of `git status -s` seems to be what I want
<ribasushi> hmmm
<ribasushi> charon: git-gh-setup's manpage does not seem to list what you gave me
<ribasushi> and the manpage says that I should not be touching it...
Leaving aside my worktree vs. work_tree mistake, he concluded that he
should not be using it even though he is a script writer.
Regardless, I don't really care enough about this one; let's just do the
first patch (v2 upcoming) so that we have documentation to point people
at.
[*] http://colabti.org/irclogger/irclogger_log/git?date=2011-12-20#l1284
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Junio C Hamano @ 2011-12-20 20:08 UTC (permalink / raw)
To: Brandon Casey; +Cc: peff, git, j6t, jrnieder, Brandon Casey
In-Reply-To: <7vty4wkx19.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> * new test cases can be dropped into the t4018 directory
>> * filenames end with the pattern name e.g. .cpp .objc .matlab etc.
>> * filenames should be descriptive since it will be used in the test
>> suite output
>> * broken test cases should be given a filename prefixed with "broken_"
>
> Cute. I like the general idea.
Actually, I do not like this "broken_" filename prefix part. Even though I
can imagine "git show -M" would do a reasonable job, marking that a fix to
a pattern makes a test that used not to pass succeed by renaming a file
goes against the convention of changing one line to turn the "failure" to
"success" in test_expect_failure used in normal tests.
Can we use stable filename that says what is being tested instead?
^ permalink raw reply
* Re: [PATCH v2] t4018: introduce test cases for the internal hunk header patterns
From: Johannes Sixt @ 2011-12-20 19:52 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git, peff, jrnieder, trast
In-Reply-To: <1324348939-27115-1-git-send-email-drafnel@gmail.com>
Am 20.12.2011 03:42, schrieb Brandon Casey:
> +int WRONG_global_variable;
Personally, I'm not a fan of this one. IMHO, global variable
definitions need not be ignored. (But I can live with it.)
But here are some more tests that I care about and that you can squash in.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/t4018/broken_class_constructor.cpp | 3 +-
t/t4018/broken_return_type_in_global_namespace.cpp | 16 ++++++++++++++
t/t4018/class_definition.cpp | 19 +++++++++++++++++
t/t4018/derived_class_definition.cpp | 20 ++++++++++++++++++
t/t4018/ignore_access_specifier.cpp | 22 ++++++++++++++++++++
5 files changed, 79 insertions(+), 1 deletions(-)
create mode 100644 t/t4018/broken_return_type_in_global_namespace.cpp
create mode 100644 t/t4018/class_definition.cpp
create mode 100644 t/t4018/derived_class_definition.cpp
create mode 100644 t/t4018/ignore_access_specifier.cpp
diff --git a/t/t4018/broken_class_constructor.cpp b/t/t4018/broken_class_constructor.cpp
index 774c7f9..28c1bc8 100644
--- a/t/t4018/broken_class_constructor.cpp
+++ b/t/t4018/broken_class_constructor.cpp
@@ -3,7 +3,8 @@ int WRONG_function_hunk_header_preceding_the_right_one (void)
return 0;
}
-RIGHT_function_hunk_header::RIGHT_function_hunk_header (void)
+RIGHT_function_hunk_header::RIGHT_function_hunk_header (int x) :
+ WRONG_member_initializer(x)
{
const char *msg = "ChangeMe";
printf("Hello, world, %s\n", msg);
diff --git a/t/t4018/broken_return_type_in_global_namespace.cpp b/t/t4018/broken_return_type_in_global_namespace.cpp
new file mode 100644
index 0000000..da9931b
--- /dev/null
+++ b/t/t4018/broken_return_type_in_global_namespace.cpp
@@ -0,0 +1,16 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+::TypeInGlobalNamespace RIGHT_function_hunk_header()
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/class_definition.cpp b/t/t4018/class_definition.cpp
new file mode 100644
index 0000000..fc3df34
--- /dev/null
+++ b/t/t4018/class_definition.cpp
@@ -0,0 +1,19 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+class RIGHT_class_name
+{
+ void WRONG_function_name_following_the_right_one()
+ {
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+ }
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/derived_class_definition.cpp b/t/t4018/derived_class_definition.cpp
new file mode 100644
index 0000000..b8501a5
--- /dev/null
+++ b/t/t4018/derived_class_definition.cpp
@@ -0,0 +1,20 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+class RIGHT_class_name :
+ public WRONG_class_name_following_the_right_one
+{
+ void WRONG_function_name_following_the_right_one()
+ {
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+ }
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/ignore_access_specifier.cpp b/t/t4018/ignore_access_specifier.cpp
new file mode 100644
index 0000000..d865040
--- /dev/null
+++ b/t/t4018/ignore_access_specifier.cpp
@@ -0,0 +1,22 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+class RIGHT_class_name
+{
+public:
+protected:
+private:
+ void WRONG_function_name_following_the_right_one()
+ {
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+ }
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
--
1.7.8.216.g2e426
^ permalink raw reply related
* Re: Escape character for .gitconfig
From: Dirk Süsserott @ 2011-12-20 19:46 UTC (permalink / raw)
To: Erik Blake; +Cc: git
In-Reply-To: <4EF04199.1010008@icefield.yk.ca>
Am 20.12.2011 09:04 schrieb Erik Blake:
> Hi Dirk,
>
> I ended up using "'C:/Program Files (x86)/Notepad++/notepad++.exe'
> -multiInst -notabbar -nosession -noPlugin" which works nicely for me
> (note the placement of the inner quotations).
>
> It is notepad.exe (the default Windows editor) that fails on files with
> only <lf> termination. That's why I was trying to set notepad++ as the
> git editor as it is vastly superior.
>
> Cheers,
> Erik
Hi Erik,
oops, I overread that you talked about notepad (not notepad++) and the
<lf> stuff. My fault. I use the portable version of notepad++ and don't
have the "space in path" problem. But if you mainly use the git-bash (as
I do) instead of cmd.exe, then probably you could tweak your .bashrc:
export PATH="/C:/Program Files (x86)/Notepad++":$PATH
and then run notepad++ w/o giving the absolute path.
Cheers,
Dirk
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: make git-sh-setup docs less scary
From: Ævar Arnfjörð Bjarmason @ 2011-12-20 19:45 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <c8867738c264a76f9662080b64e00615ec1aa28f.1324378986.git.trast@student.ethz.ch>
On Tue, Dec 20, 2011 at 12:09, Thomas Rast <trast@student.ethz.ch> wrote:
> At least one IRC user was scared away by the introductory "This is not
> a command the end user would want to run. Ever." to the point of not
> reading on.
Arguably that's the point isn't it? To not have people who aren't
maintaining Git itself waste time on reading it.
Anyway I don't care how it's worded, but if you're going to patch it
you should probably do these too for consistency, since they
copy/paste this same blurb:
$ git --no-pager grep -l 'This is not a command the end user would
want to run. Ever.'
Documentation/git-mergetool--lib.txt
Documentation/git-sh-i18n--envsubst.txt
Documentation/git-sh-i18n.txt
Documentation/git-sh-setup.txt
And actually we might want to do all those with some asciidoc include
mechanism.
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Joshua Redstone @ 2011-12-20 19:26 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, Carlos Martín Nieto,
Tomas Carnecky, git@vger.kernel.org
In-Reply-To: <87wr9rk35n.fsf@thomas.inf.ethz.ch>
I looked again at my poor-mans-profiling output of git-add. The Sha1
stuff under ce_write_entry->ce_write_flush takes a bunch of time.
commit_lock_file->rename takes about the same as well.
Btw, the perf numbers for commit and add are with a warm file cache. I
expect the benefit of skipping all the stat() calls will increase for cold
cache.
Josh
On 12/20/11 1:23 AM, "Thomas Rast" <trast@student.ethz.ch> wrote:
>Joshua Redstone <joshua.redstone@fb.com> writes:
>> As a bonus, I've also profiled git-add on the 1-million file repo, and
>>it
>> looks like, as you might expect, the time is dominated by reading and
>> writing the index. The time for git-add is a couple of seconds.
>
>Note that the time to write the index itself is also rather small, but
>the time needed to sha1 the index when loading and then again when
>saving it really hurts.
>
>(I noticed this while working on the commit-tree topic.)
>
>--
>Thomas Rast
>trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 1/2] git-sh-setup: make require_clean_work_tree part of the interface
From: Junio C Hamano @ 2011-12-20 19:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <c53feb0de8006c205fd26c2c07dcd78bd86b6c24.1324378986.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> 92c62a3 (Porcelain scripts: Rewrite cryptic "needs update" error
> message, 2010-10-19) refactored git's own checking to a function in
> git-sh-setup. This is a very useful thing for script writers, so
> document it.
Can we avoid explaining "clean" with the same word "clean", which adds no
new information? IOW, what does "clean" mean in the context of this helper
shell function? No untracked cruft? No un-added changes? What are the kind
of dirtiness being checked?
> +require_clean_work_tree <action> [<hint>]::
> + checks if the working tree associated with the repository is
> + clean. Otherwise it emits an error message of the form
> + `Cannot <action>: <reason>. <hint>`, and dies. Example:
> ++
> +----------------
> +require_clean_work_tree rebase "Please commit or stash them."
> +----------------
> +
> get_author_ident_from_commit::
> outputs code for use with eval to set the GIT_AUTHOR_NAME,
> GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: make git-sh-setup docs less scary
From: Junio C Hamano @ 2011-12-20 19:20 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <c8867738c264a76f9662080b64e00615ec1aa28f.1324378986.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> At least one IRC user was scared away by the introductory "This is not
> a command the end user would want to run. Ever." to the point of not
> reading on.
You would need to say what that IRC user needed to find out. Depending on
that, letting the user know that there is no point reading on early and
not waste his or her time may be a good thing. That was what the paragraph
was designed for. IOW, it is not to "scare" away, but to allow the users
to decide if they are intended audiences.
The reworded version does avoid sounding scary, but loses the "this
document is for people who want to write new or understand existing
Porcelain scripts", which is a documentation regression.
> Reword it in a more matter-of-fact way that does not intentionally try
> to scare the user away. Since 46bac90 (Do not install shell libraries
> executable, 2010-01-31) it is not executable anyway, so the end user
> would get
>
> $ git sh-setup
> fatal: cannot exec 'git-sh-setup': Permission denied
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
> Documentation/git-sh-setup.txt | 11 ++++-------
> 1 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
> index bbfefca..612fb50 100644
> --- a/Documentation/git-sh-setup.txt
> +++ b/Documentation/git-sh-setup.txt
> @@ -13,13 +13,10 @@ SYNOPSIS
> DESCRIPTION
> -----------
>
> -This is not a command the end user would want to run. Ever.
> -This documentation is meant for people who are studying the
> -Porcelain-ish scripts and/or are writing new ones.
> -
> -The 'git sh-setup' scriptlet is designed to be sourced (using
> -`.`) by other shell scripts to set up some variables pointing at
> -the normal git directories and a few helper shell functions.
> +This command cannot be run by the end user. Shell scripts can
> +source it (using `.` as indicated above) to set up some variables
> +pointing at the normal git directories and a few helper shell
> +functions.
>
> Before sourcing it, your script should set up a few variables;
> `USAGE` (and `LONG_USAGE`, if any) is used to define message
^ permalink raw reply
* Re: [PATCH v2] t4018: introduce test cases for the internal hunk header patterns
From: Brandon Casey @ 2011-12-20 15:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: gitster, git, peff, j6t, jrnieder, trast
In-Reply-To: <m3pqfjfy42.fsf@localhost.localdomain>
On Tue, Dec 20, 2011 at 2:25 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> diff --git a/t/t4018/ignore_global.cpp b/t/t4018/ignore_global.cpp
>> new file mode 100644
>> index 0000000..95e23bc
>> --- /dev/null
>> +++ b/t/t4018/ignore_global.cpp
>> @@ -0,0 +1,19 @@
>> +int WRONG_function_hunk_header_preceding_the_right_one (void)
>> +{
>> + return 0;
>> +}
>> +
>> +int RIGHT_function_hunk_header (void)
>> +{
>> + printf("Hello, world\n");
>> + return 0;
>> +}
>> +
>> +int WRONG_global_variable;
>> +
>> +int ChangeMe;
>> +
>> +int WRONG_function_hunk_header_following_the_right_one (void)
>> +{
>> + return 0;
>> +}
>
> Shouldn't ChangeMe be inside function?
No, this one is placed here after the WRONG_global_variable to make
sure that a global variable is not chosen for the hunk header. It
should chose the most recently encountered function name for the hunk
header, which is RIGHT_function_hunk_header.
>> diff --git a/t/t4018/simple.cpp b/t/t4018/simple.cpp
>> new file mode 100644
>> index 0000000..c96ad87
>> --- /dev/null
>> +++ b/t/t4018/simple.cpp
>> @@ -0,0 +1,32 @@
>> +/*
>> + * Test file for testing the internal hunk header patterns
>> + *
>> + * The "RIGHT" hunk header function, the one that should appear on the
>> + * hunk header line, should be named "RIGHT_function_hunk_header" and
>> + * the body of this function should have an assignment that looks like
>> + *
>> + * answer = 0
>
> Shouldn't it be ChangeMe?
Whoops, I forgot about that text. Thanks for noticing. Yes this is
incorrect now. I think I'll break that out into a README file.
v3 forthcoming.
-Brandon
^ permalink raw reply
* Metadata storage - let's do this (was: "Tracking file metadata in git -- fix metastore or enhance git?") (was: "Revisiting metadata storage")
From: Richard Hartmann @ 2011-12-20 15:45 UTC (permalink / raw)
To: Git List
Cc: jrnieder, Ronan Keryell, hilco.wijbenga, Thorsten Glaser,
git.nabble.com
Hi all,
to summarize the current situation: quite a few people want to have
this, but no one seems to be willing to actually jump into the cold
water and swim.
I decided to scratch my own itch and started to collect requirements,
etc. Obviously, those are mine. I can already tell you that I will
focus on mtime and possibly EXIF support as that is what I need this
whole thing for.
You are very welcome to comment on any of this.
Please note that I decided not to tie this into git but to use a
separate file. The rationale being that, this way, normal git
operations are not impacted in any way and allowing re-use elsewhere.
General:
* Must work with non-git
* Must play nicely with git
** Must merge easily when there are no conflicts
** Must conflict merges if layout version is changed
* No XML as that does not merge
* Assuming I spear-head this effort, it will be in Perl 5
* Possible names include
** metamonger
** metamangler
** git meta
* Needs test suite
Storage:
* Versioned storage layout
* Tab-seperated list (handle file names containing tabs via escaping?)
* UTF-8 for file names, ISO-8859-1 for metadata
* All binary data, if any (support for xattr?) will be ASCII-armoured
* Metadata will be both machine and human readable _and_ explicitly be
designed to facilitate manual editing
Syntax:
$0 save # save metadata, recursively, to .meta.db
$0 apply # apply metadata, recursively, from .meta.db
$0 diff # guess.
-q : quiet
-m : comma-seperated list to override what data will be stored/applied/diffed
-f : specify file name to store to/apply from
-F: store to/apply from .meta.db.$HOSTNAME
-U: store to/apply from .meta.db.$(cat /etc/hostuuid)
--exif-db : EXIF <> db
--exif-file : EXIF <> file
I would like to have this tool be able to operate on EXIF data to see
if the file's mtime and creation time are the same. Very specific use
case, but hey. Maybe factor that out into a cleanly modularized system
and call if via a more generic interface, though
Depending on the feedback I get and how busy I am before christmas, I
may get an initial version up and running before 2012.
If you want to help, nag or anything, please do it asap.
Thanks,
Richard
^ permalink raw reply
* Rewriting history and public-private-ish branches
From: Jay Levitt @ 2011-12-20 12:33 UTC (permalink / raw)
To: git@vger.kernel.org
I frequently conflate git-as-version-control with git-as-deployer when I'm
editing on my Mac but testing on a server. I'll do things like...
Mac: checkout -b origin/topic-branch
Mac: make a major change, commit and push
server: pull
[do while buggy]
server: discover a typo
Mac: fix the typo, commit and push
server: pull
[end]
Mac: squash commits
Mac: checkout master
Mac: merge topic-branch
Mac: branch -d topic-branch
Mac: push origin :topic-branch
As long as I'm the only one who's seen this "published" history, am I doing
anything bad? Do I leave any residue behind in the repo?
Jay Levitt
^ permalink raw reply
* Re: git-p4: labels
From: Vitor Antunes @ 2011-12-20 12:03 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Luke Diamand, Git List, Michael Horowitz
In-Reply-To: <20111220014753.GD20591@padd.com>
On Tue, Dec 20, 2011 at 1:47 AM, Pete Wyckoff <pw@padd.com> wrote:
> But adding a new command to go back and look for _new_ labels
> makes sense too. Finding the new ones isn't so bad, given that
> p4 can just print them directly, and we keep them as tags in git.
Now that you say that, it is now very difficult to detect branches on an
already imported repository. Maybe the new command could also do that?
In this case I would call it "git-p4 resync".
> [...]
> But isn't there a step in label detection that looks an awful lot
> like branch point detection? You've got a label, which is a
> bunch of files, not a p4 change number. Now you have to figure
> out the change number so you can go hunt that down in the git
> history. Vitor's take on this was to use git diff machinery to
> find it, not trawling through the p4 change/filelog/describe
> history, mainly because it's likely much faster to do it locally
> in git.
In labels this is easier and fast:
p4 changes -m 1 @label_name
Then we could diff the label against the changelist. If equal simply tag
the commit, if different then we need to create a temporary branch to
commit the changes and tag that instead.
--
Vitor Antunes
^ permalink raw reply
* [PATCH 2/2] Documentation: make git-sh-setup docs less scary
From: Thomas Rast @ 2011-12-20 11:09 UTC (permalink / raw)
To: git
In-Reply-To: <c53feb0de8006c205fd26c2c07dcd78bd86b6c24.1324378986.git.trast@student.ethz.ch>
At least one IRC user was scared away by the introductory "This is not
a command the end user would want to run. Ever." to the point of not
reading on.
Reword it in a more matter-of-fact way that does not intentionally try
to scare the user away. Since 46bac90 (Do not install shell libraries
executable, 2010-01-31) it is not executable anyway, so the end user
would get
$ git sh-setup
fatal: cannot exec 'git-sh-setup': Permission denied
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-sh-setup.txt | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index bbfefca..612fb50 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -13,13 +13,10 @@ SYNOPSIS
DESCRIPTION
-----------
-This is not a command the end user would want to run. Ever.
-This documentation is meant for people who are studying the
-Porcelain-ish scripts and/or are writing new ones.
-
-The 'git sh-setup' scriptlet is designed to be sourced (using
-`.`) by other shell scripts to set up some variables pointing at
-the normal git directories and a few helper shell functions.
+This command cannot be run by the end user. Shell scripts can
+source it (using `.` as indicated above) to set up some variables
+pointing at the normal git directories and a few helper shell
+functions.
Before sourcing it, your script should set up a few variables;
`USAGE` (and `LONG_USAGE`, if any) is used to define message
--
1.7.8.484.gdad4270
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox