* [PATCH 2/2 v2] valgrind: ignore ldso errors
From: Johannes Schindelin @ 2009-01-21 1:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901210216440.19014@racer>
On some Linux systems, we get a host of Cond and Addr errors
from calls to dlopen that are caused by nss modules. We
should be able to safely ignore anything happening in
ld-*.so as "not our problem."
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Only change vs v1: adds Addr4 suppression, so that ld.so "errors"
are ignored on 32-bit, too.
t/valgrind/default.supp | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/t/valgrind/default.supp b/t/valgrind/default.supp
index 2482b3b..6061283 100644
--- a/t/valgrind/default.supp
+++ b/t/valgrind/default.supp
@@ -11,6 +11,24 @@
}
{
+ ignore-ldso-cond
+ Memcheck:Cond
+ obj:*ld-*.so
+}
+
+{
+ ignore-ldso-addr8
+ Memcheck:Addr8
+ obj:*ld-*.so
+}
+
+{
+ ignore-ldso-addr4
+ Memcheck:Addr4
+ obj:*ld-*.so
+}
+
+{
writing-data-from-zlib-triggers-errors
Memcheck:Param
write(buf)
--
1.6.1.243.g6c8bb35
^ permalink raw reply related
* Re: [PATCH] Add --contains flag to git tag
From: Jake Goulding @ 2009-01-21 1:37 UTC (permalink / raw)
To: git
In-Reply-To: <1232501631-21531-3-git-send-email-goulding@vivisimo.com>
Ack - I sent that a bit before I meant to (and before I added patch sequence numbers).
This is a patch that adds a --contains flag to git tag, providing similar functionality as git branch --contains.
Please let me know what else I have inevitably messed up, and I shall endeavor to fix and resubmit.
-Jake
----- Original Message -----
From: "Jake Goulding" <goulding@vivisimo.com>
To: git@vger.kernel.org
Cc: "Jake Goulding" <goulding@vivisimo.com>
Sent: Tuesday, January 20, 2009 8:33:49 PM GMT -05:00 US/Canada Eastern
Subject: [PATCH] Add --contains flag to git tag
This functions similar to how --contains works for git branch - it
will show all tags that contain the specified commit. Indeed, it uses
the same lookup mechanisms as git branch.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
builtin-tag.c | 28 ++++++++++++++++++++++++++--
1 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index a398499..453ed26 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -26,6 +26,7 @@ static char signingkey[1000];
struct tag_filter {
const char *pattern;
int lines;
+ struct commit_list *with_commit;
};
#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
@@ -35,6 +36,15 @@ static int show_reference(const char *refname, const unsigned char *sha1,
{
struct tag_filter *filter = cb_data;
+ if (filter->with_commit) {
+ struct commit *commit;
+
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit)
+ return error("branch '%s' does not point at a commit", refname);
+ if (!has_commit(commit, filter->with_commit))
+ return 0;
+ }
if (!fnmatch(filter->pattern, refname, 0)) {
int i;
unsigned long size;
@@ -79,7 +89,8 @@ static int show_reference(const char *refname, const unsigned char *sha1,
return 0;
}
-static int list_tags(const char *pattern, int lines)
+static int list_tags(const char *pattern, int lines,
+ struct commit_list *with_commit)
{
struct tag_filter filter;
@@ -88,6 +99,7 @@ static int list_tags(const char *pattern, int lines)
filter.pattern = pattern;
filter.lines = lines;
+ filter.with_commit = with_commit;
for_each_tag_ref(show_reference, (void *) &filter);
@@ -360,6 +372,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
list = 0, delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
+ struct commit_list *with_commit = NULL;
struct option options[] = {
OPT_BOOLEAN('l', NULL, &list, "list tag names"),
{ OPTION_INTEGER, 'n', NULL, &lines, NULL,
@@ -378,6 +391,14 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_STRING('u', NULL, &keyid, "key-id",
"use another key to sign the tag"),
OPT_BOOLEAN('f', NULL, &force, "replace the tag if exists"),
+
+ OPT_GROUP("Tag listing options"),
+ {
+ OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
+ "print only tags that contain the commit",
+ PARSE_OPT_LASTARG_DEFAULT,
+ parse_opt_with_commit, (intptr_t)"HEAD",
+ },
OPT_END()
};
@@ -402,9 +423,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (list + delete + verify > 1)
usage_with_options(git_tag_usage, options);
if (list)
- return list_tags(argv[0], lines == -1 ? 0 : lines);
+ return list_tags(argv[0], lines == -1 ? 0 : lines,
+ with_commit);
if (lines != -1)
die("-n option is only allowed with -l.");
+ if (with_commit)
+ die("--contains option is only allowed with -l.");
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
--
1.6.0.6
^ permalink raw reply related
* unmerged flag at git diff-index
From: Frank Li @ 2009-01-21 2:13 UTC (permalink / raw)
To: git
There are conflict when I call git merge
git ls-files -u
100644 54d05e1c40c686027b611b702e014284e9ab9a31 1 a.c
100644 a8a1b77c0d92f33491a0a69a8645f02ececb1eb6 2 a.c
100644 642ba972b2234f63048abcca544b3926f94e04ee 3 a.c
but when use git diff-index HEAD
:100644 100644 a8a1b77c0d92f33491a0a69a8645f02ececb1eb6 0000000000000000000000
0000000000000000 M a.c
a.c flag is M: Modification of the contents or mode of a file.
I think it should be U: file is unmerged(you must complete the merge
before it can be commited)
^ permalink raw reply
* Re: unmerged flag at git diff-index
From: Junio C Hamano @ 2009-01-21 2:40 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901201813r7b03525ax39fd0e1ecfb1700e@mail.gmail.com>
Frank Li <lznuaa@gmail.com> writes:
> There are conflict when I call git merge
> git ls-files -u
> 100644 54d05e1c40c686027b611b702e014284e9ab9a31 1 a.c
> 100644 a8a1b77c0d92f33491a0a69a8645f02ececb1eb6 2 a.c
> 100644 642ba972b2234f63048abcca544b3926f94e04ee 3 a.c
>
> but when use git diff-index HEAD
> :100644 100644 a8a1b77c0d92f33491a0a69a8645f02ececb1eb6 0000000000000000000000
> 0000000000000000 M a.c
>
> a.c flag is M: Modification of the contents or mode of a file.
That is correct.
By asking "git diff-index HEAD", you are asking to compare the work tree
contents through the index against HEAD commit. The work tree path by
definition cannot be "unmerged" as there is no stages in the work tree.
"git diff-index --cached HEAD" would compare the index against the HEAD
commit, and would say it is unmerged.
^ permalink raw reply
* Re: unmerged flag at git diff-index
From: Johannes Schindelin @ 2009-01-21 2:48 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901201813r7b03525ax39fd0e1ecfb1700e@mail.gmail.com>
Hi,
On Wed, 21 Jan 2009, Frank Li wrote:
> There are conflict when I call git merge
> git ls-files -u
> 100644 54d05e1c40c686027b611b702e014284e9ab9a31 1 a.c
> 100644 a8a1b77c0d92f33491a0a69a8645f02ececb1eb6 2 a.c
> 100644 642ba972b2234f63048abcca544b3926f94e04ee 3 a.c
>
> but when use git diff-index HEAD
> :100644 100644 a8a1b77c0d92f33491a0a69a8645f02ececb1eb6 0000000000000000000000
> 0000000000000000 M a.c
>
> a.c flag is M: Modification of the contents or mode of a file.
>
> I think it should be U: file is unmerged(you must complete the merge
> before it can be commited)
You're talking plumbing here. And diff-index is about the differences
between the working directory and the index _stage 0_.
I don't think that's a bug (what would you display? stage 1? stage 2?
stage 3?), but even if it weren't, it is plumbing, and plumbing's UI is
guaranteed to be stable.
So I guess that you really have to use "git ls-files --stage" at some
stage :-)
Ciao,
Dscho
^ permalink raw reply
* Re: John (zzz) Doe <john.doe@xz> (Comment)
From: Junio C Hamano @ 2009-01-21 3:12 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Johannes Schindelin, git
In-Reply-To: <20090120191446.GB5721@roro3.zxlink>
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> On Sun, Jan 18, 2009 at 10:50:12AM -0800, Junio C Hamano wrote:
>> So we can separate "John (zzz) Doe <john.doe@xz> (Comment)" into:
>>
>> AUTHOR_EMAIL=john.doe@xz
>> AUTHOR_NAME="John (zzz) Doe (Comment)"
>>
>> and leave it like so, I think.
>
> Ok, here you are:
>
> Subject: [PATCH 1/3] mailinfo: cleanup extra spaces for complex 'From'
>
> As described in RFC822 (3.4.3 COMMENTS, and A.1.4.), comments, as e.g.
>
> John (zzz) Doe <john.doe@xz> (Comment)
>
> should "NOT [be] included in the destination mailbox"
>
> On the other hand, quoting Junio:
>
>> The above quote from the RFC is irrelevant. Note that it is only about
>> how you extract the e-mail address, discarding everything else.
>>
>> What mailinfo wants to do is to separate the human-readable name and the
>> e-mail address, and we want to use _both_ results from it.
>>
>> We separate a few example From: lines like this:
>>
>> Kirill Smelkov <kirr@smelkov.xz>
>> ==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
>>
>> kirr@smelkov.xz (Kirill Smelkov)
>> ==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
>>
>> Traditionally, the way people spelled their name on From: line has been
>> either one of the above form. Typically comment form (i.e. the second
>> one) adds the name at the end, while "Name <addr>" form has the name at
>> the front. But I do not think RFC requires that, primarily because it is
>> all about discarding non-address part to find the e-mail address aka
>> "destination mailbox". It does not specify how humans should interpret
>> the human readable name and the comment.
>>
>> Now, why is the name not AUTHOR_NAME="(Kirill Smelkov)" in the latter
>> form?
>>
>> It is just common sense transformation. Otherwise it looks simply ugly,
>> and it is obvious that the parentheses is not part of the name of the
>> person who used "kirr@smelkov.xz (Kirill Smelkov)" on his From: line.
>>
>> So we can separate "John (zzz) Doe <john.doe@xz> (Comment)" into:
>>
>> AUTHOR_EMAIL=john.doe@xz
>> AUTHOR_NAME="John (zzz) Doe (Comment)"
>>
>> and leave it like so, I think.
>
> So let's just correctly remove extra spaces which could be left inside
> name.
>
> We need this functionality to pass all RFC2047 based tests in the next commit.
>
> Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> ---
> ...
> Is it ok?
I think the patch text looks good, but what you have as the proposed
commit log message does not look anything like log message we usually use.
- If you agree with my comment that "should NOT be included" from the RFC
you quoted is irrelevant, then I do not think you would even want to
have anything before "On the other hand,...".
- If you disagree, then why are you bending the patch text to match what
I say? ;-)
Also I am not sure "passing RFC2047 based tests" is a valid purpose nor
justification for adding this patch (because you could argue that the
tests and the results the tests expect are faulty).
The way we (and your patches) do thinks is to have the desired outcome
designed first, and then have tests to make sure that the implementation
matches the desired outcome.
Given that, what I would probably suggest would be...
-- 8< -- cut from here -- 8< --
mailinfo: handle comment fields in From: line sanely
Most commonly, people have their human readable name and their e-mail
address on their From: line in one of two formats:
Kirill Smelkov <kirr@smelkov.xz>
kirr@smelkov.xz (Kirill Smelkov)
In addition, you can have "Comments" in parentheses at random places, like
this:
John (zzz) Doe <john.doe@xz> (Comment)
RFC822 defines rules to extract the "destination mailbox" out of such
input (and we correctly extract "kirr@smelkov.xz" and "john.doe@xz" from
these examples). It however does not specify how to pick up the human
readable name from the remainder, and the existing code randomly dropped
pieces of information in <<<this and that way --- explain the breakage you
wanted to fix with your patch, perhaps "and left a newline in the result"
may be one of the breakages>>>.
This patch changes the rule so that <<<explain what it does here. I think
what the code does is (1) remove the e-mail (and angle brackets around
it), (2) sanitize LF into a single SP to keep the result a single line,
and (3) as a special case, if the result is enclosed by () pair, remove
them---this rule is to format the second common case listed above
sanely>>>.
A subsequent patch using From: lines taken from the example section of
RFC2047 will test this feature.
-- >8 --
^ permalink raw reply
* Re: [PATCH] [TOPGIT] make creating a commit from a topgit branch a function
From: martin f krafft @ 2009-01-21 3:19 UTC (permalink / raw)
To: Uwe Kleine-König, git, Petr Baudis
In-Reply-To: <1231968443-13960-2-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.01.15.0827 +1100]:
> This helps avoiding code duplication for the next commit.
What's the "next commit"?
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
i'd rather be riding a high speed tractor
with a beer on my lap,
and a six pack of girls next to me.
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add --contains flag to git tag
From: Miklos Vajna @ 2009-01-21 3:20 UTC (permalink / raw)
To: Jake Goulding; +Cc: git
In-Reply-To: <4448209.246381232501828959.JavaMail.root@scalix.vivisimo.com>
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
On Tue, Jan 20, 2009 at 08:37:09PM -0500, Jake Goulding <goulding@vivisimo.com> wrote:
> Please let me know what else I have inevitably messed up, and I shall
> endeavor to fix and resubmit.
Please document your improvements in Documentation/git-tag.txt and don't
forget to add a testcase to t7004-tag.sh.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH (topgit)] tg-patch: add support for generating patches against worktree and index
From: martin f krafft @ 2009-01-21 3:20 UTC (permalink / raw)
To: Kirill Smelkov, Petr Baudis, Git Mailing List
In-Reply-To: <20090120175635.GA5721@roro3.zxlink>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2009.01.21.0456 +1100]:
> No problem and take your time.
>
> It was just me having no idea about what's going on.
I am a little confused about the patches, and git-am does not seem
to be able to apply two patches from the same email. I use Maildir,
so I am passing the single message with multiple patches to git-am,
and it applies all changes into one single commit.
Anyway, do you have a repo which I can cherry-pick from?
--
martin | http://madduck.net/ | http://two.sentenc.es/
"out of the crooked timber of humanity,
no straight thing was ever made."
-- imanuel kant
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] color-words: Support diff.color-words config option
From: Boyd Stephen Smith Jr. @ 2009-01-21 3:46 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901201058520.3586@pacific.mpi-cbg.de>
When diff is invoked with --color-words (w/o =regex), use the regular
expression the user has configured as diff.wordregex.
diff drivers configured via attributes take precedence over the
diff.wordregex-words setting. If the user wants to change them, they have
their own configuration variables.
Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
---
This version is squashed into one patch and includes documentation and
rewritten tests. It was generated against js/diff-color-words~2,
80c49c3d (color-words: make regex configurable via attributes), replacing
my previous 2 patches. It uses "diff.wordregex" for reasons mention by
Dscho and because that was already what the diff drivers were using.
I'm not entirely satisfied with it. There should probably be some way
to force the default behavior (which is a bit faster) even if a global
config or diff driver exists. Also, I think camelCase is better than
runtogether so I'd prefer to change "wordregex" -> "wordRegex" across
the entire patch set.
Documentation/config.txt | 6 +++++
Documentation/diff-options.txt | 7 +++--
diff.c | 5 ++++
t/t4034-diff-words.sh | 45 ++++++++++++++++++++++++++++++++++++++-
4 files changed, 58 insertions(+), 5 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7408bb2..0ca983a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -639,6 +639,12 @@ diff.suppress-blank-empty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
+diff.wordregex::
+ A POSIX Extended Regular Expression used to determine what is a "word"
+ when performing word-by-word difference calculations. Character
+ sequences that match the regular expression are "words", all other
+ characters are *ignorable* whitespace.
+
fetch.unpackLimit::
If the number of objects fetched over the git native
transfer is below this
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 1edb82e..164e2c5 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -103,9 +103,10 @@ expression to make sure that it matches all non-whitespace characters.
A match that contains a newline is silently truncated(!) at the
newline.
+
-The regex can also be set via a diff driver, see
-linkgit:gitattributes[1]; giving it explicitly overrides any diff
-driver setting.
+The regex can also be set via a diff driver or configuration option, see
+linkgit:gitattributes[1] or linkgit:git-config[1]. Giving it explicitly
+overrides any diff driver or configuration setting. Diff drivers
+override configuration settings.
--no-renames::
Turn off rename detection, even when the configuration
diff --git a/diff.c b/diff.c
index 9fcde96..ed8b83c 100644
--- a/diff.c
+++ b/diff.c
@@ -23,6 +23,7 @@ static int diff_detect_rename_default;
static int diff_rename_limit_default = 200;
static int diff_suppress_blank_empty;
int diff_use_color_default = -1;
+static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
@@ -92,6 +93,8 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
}
if (!strcmp(var, "diff.external"))
return git_config_string(&external_diff_cmd_cfg, var, value);
+ if (!strcmp(var, "diff.wordregex"))
+ return git_config_string(&diff_word_regex_cfg, var, value);
return git_diff_basic_config(var, value, cb);
}
@@ -1550,6 +1553,8 @@ static void builtin_diff(const char *name_a,
o->word_regex = userdiff_word_regex(one);
if (!o->word_regex)
o->word_regex = userdiff_word_regex(two);
+ if (!o->word_regex)
+ o->word_regex = diff_word_regex_cfg;
if (o->word_regex) {
ecbdata.diff_words->word_regex = (regex_t *)
xmalloc(sizeof(regex_t));
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 744221b..6bcc153 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -77,6 +77,7 @@ a = b + c<RESET>
<GREEN>aeff = aeff * ( aaa<RESET> )
EOF
+cp expect expect.letter-runs-are-words
test_expect_success 'word diff with a regular expression' '
@@ -92,7 +93,7 @@ post diff=testdriver
EOF
'
-test_expect_success 'option overrides default' '
+test_expect_success 'option overrides .gitattributes' '
word_diff --color-words="[a-z]+"
@@ -112,13 +113,53 @@ a = b + c<RESET>
<GREEN>aeff = aeff * ( aaa )<RESET>
EOF
+cp expect expect.non-whitespace-is-word
-test_expect_success 'use default supplied by driver' '
+test_expect_success 'use regex supplied by driver' '
word_diff --color-words
'
+test_expect_success 'set diff.wordregex option' '
+ git config diff.wordregex "[[:alnum:]]+"
+'
+
+cp expect.letter-runs-are-words expect
+
+test_expect_success 'command-line overrides config' '
+ word_diff --color-words="[a-z]+"
+'
+
+cp expect.non-whitespace-is-word expect
+
+test_expect_success '.gitattributes override config' '
+ word_diff --color-words
+'
+
+test_expect_success 'remove diff driver regex' '
+ git config --unset diff.testdriver.wordregex
+'
+
+cat > expect <<\EOF
+<WHITE>diff --git a/pre b/post<RESET>
+<WHITE>index 330b04f..5ed8eff 100644<RESET>
+<WHITE>--- a/pre<RESET>
+<WHITE>+++ b/post<RESET>
+<BROWN>@@ -1,3 +1,7 @@<RESET>
+h(4),<GREEN>hh[44<RESET>]
+<RESET>
+a = b + c<RESET>
+
+<GREEN>aa = a<RESET>
+
+<GREEN>aeff = aeff * ( aaa<RESET> )
+EOF
+
+test_expect_success 'use configured regex' '
+ word_diff --color-words
+'
+
echo 'aaa (aaa)' > pre
echo 'aaa (aaa) aaa' > post
--
1.5.6.5
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply related
* Re: [PATCH] Add --contains flag to git tag
From: Jake Goulding @ 2009-01-21 3:54 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090121032058.GG21473@genesis.frugalware.org>
That is actually in a subsequent commit (in my unmarked patch sequence).
I actually have 1 commit for the code change, one for documentation, and one for the test case. Should I squash all these together?
Also, my test case is in a separate file (t7704-tag-contains.sh) as that is how I read t/README. Was this incorrect?
Thanks!
-Jake
----- Original Message -----
From: "Miklos Vajna" <vmiklos@frugalware.org>
To: "Jake Goulding" <goulding@vivisimo.com>
Cc: git@vger.kernel.org
Sent: Tuesday, January 20, 2009 10:20:58 PM GMT -05:00 US/Canada Eastern
Subject: Re: [PATCH] Add --contains flag to git tag
On Tue, Jan 20, 2009 at 08:37:09PM -0500, Jake Goulding <goulding@vivisimo.com> wrote:
> Please let me know what else I have inevitably messed up, and I shall
> endeavor to fix and resubmit.
Please document your improvements in Documentation/git-tag.txt and don't
forget to add a testcase to t7004-tag.sh.
^ permalink raw reply
* [PATCH] Change the spelling of "wordregex".
From: Boyd Stephen Smith Jr. @ 2009-01-21 4:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901202146.58651.bss@iguanasuicide.net>
Use "wordRegex" for configuration variable names. Use "word_regex" for C
language tokens.
Signed-off-by: Boyd Stephen Smith Jr. <bss@iguanasuicide.net>
---
On Tuesday 20 January 2009, "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote about '[PATCH]
color-words: Support diff.color-words config option':
>I'm not entirely satisfied with it. [...] I think camelCase is better than
>runtogether so I'd prefer to change "wordregex" -> "wordRegex" across
>the entire patch set.
Here's a patch that does something like that, that can be squashed into the
previous patch.
Documentation/config.txt | 2 +-
Documentation/gitattributes.txt | 4 ++--
t/t4034-diff-words.sh | 8 ++++----
userdiff.c | 4 ++--
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0ca983a..332213e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -639,7 +639,7 @@ diff.suppress-blank-empty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
-diff.wordregex::
+diff.wordRegex::
A POSIX Extended Regular Expression used to determine what is a "word"
when performing word-by-word difference calculations. Character
sequences that match the regular expression are "words", all other
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index ba3ba12..227934f 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -341,14 +341,14 @@ Customizing word diff
You can customize the rules that `git diff --color-words` uses to
split words in a line, by specifying an appropriate regular expression
-in the "diff.*.wordregex" configuration variable. For example, in TeX
+in the "diff.*.wordRegex" configuration variable. For example, in TeX
a backslash followed by a sequence of letters forms a command, but
several such commands can be run together without intervening
whitespace. To separate them, use a regular expression such as
------------------------
[diff "tex"]
- wordregex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+"
+ wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+"
------------------------
A built-in pattern is provided for all languages listed in the
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 6bcc153..4508eff 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -86,7 +86,7 @@ test_expect_success 'word diff with a regular expression' '
'
test_expect_success 'set a diff driver' '
- git config diff.testdriver.wordregex "[^[:space:]]" &&
+ git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
@@ -121,8 +121,8 @@ test_expect_success 'use regex supplied by driver' '
'
-test_expect_success 'set diff.wordregex option' '
- git config diff.wordregex "[[:alnum:]]+"
+test_expect_success 'set diff.wordRegex option' '
+ git config diff.wordRegex "[[:alnum:]]+"
'
cp expect.letter-runs-are-words expect
@@ -138,7 +138,7 @@ test_expect_success '.gitattributes override config' '
'
test_expect_success 'remove diff driver regex' '
- git config --unset diff.testdriver.wordregex
+ git config --unset diff.testdriver.wordRegex
'
cat > expect <<\EOF
diff --git a/userdiff.c b/userdiff.c
index 2b55509..d556da9 100644
--- a/userdiff.c
+++ b/userdiff.c
@@ -6,8 +6,8 @@ static struct userdiff_driver *drivers;
static int ndrivers;
static int drivers_alloc;
-#define PATTERNS(name, pattern, wordregex) \
- { name, NULL, -1, { pattern, REG_EXTENDED }, wordregex }
+#define PATTERNS(name, pattern, word_regex) \
+ { name, NULL, -1, { pattern, REG_EXTENDED }, word_regex }
static struct userdiff_driver builtin_drivers[] = {
PATTERNS("html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$",
"[^<>= \t]+|[^[:space:]]|[\x80-\xff]+"),
--
1.5.6.5
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply related
* what are plumbing and porcelain
From: bill lam @ 2009-01-21 5:27 UTC (permalink / raw)
To: git
Sorry for this idiot question, but I really don't know what they are
and why it is necessary to distinguish between them.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩318 李白 清平調三首之二
一枝紅豔露凝香 雲雨巫山枉斷腸 借問漢宮誰得似 可憐飛燕倚新妝
^ permalink raw reply
* Re: what are plumbing and porcelain
From: Boyd Stephen Smith Jr. @ 2009-01-21 5:50 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090121052741.GC6970@b2j>
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
On Tuesday 20 January 2009, bill lam <cbill.lam@gmail.com> wrote
about 'what are plumbing and porcelain':
>Sorry for this idiot question, but I really don't know what they are
>and why it is necessary to distinguish between them.
"plumbing" are the commands that do low-level operations. Generally,
end-users won't have to use them much, if at all, but they
are "fundamental" operations, upon which git is built. It's a term also
used in other project some, with a similar meaning.
"porcelain" is a cute name for the end-user operations. They "cover" the
plumbing to make it look and act "pretty". While some may be less useful
to some users, they all are high-level operations that depend on the
plumbing.
It's important to distinguish between them because we don't want the
plumbing to get needlessly complex. They should be single-purpose
commands and their options should be utilitarian in nature. Also,
porcelain is meant to be used interactively, not in scripts, so the output
or behavior might change a bit--but that is still kept to a minimum.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: what are plumbing and porcelain
From: bill lam @ 2009-01-21 6:07 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901202350.15011.bss@iguanasuicide.net>
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> "plumbing" are the commands that do low-level operations. Generally,
> end-users won't have to use them much, if at all, but they
I can see now gitk should probably be porcelain. But how about
commands such as git add or git rebase used with either the -i switch
on or off?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩299 李商隱 寄令狐郎中
嵩雲秦樹久離居 雙鯉迢迢一紙筆 休問梁園舊賓客 茂陵秋雨病相如
^ permalink raw reply
* Re: what are plumbing and porcelain
From: Boyd Stephen Smith Jr. @ 2009-01-21 6:51 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090121060726.GE6970@b2j>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
On Wednesday 21 January 2009, bill lam <cbill.lam@gmail.com> wrote
about 'Re: what are plumbing and porcelain':
>On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
>> "plumbing" are the commands that do low-level operations. Generally,
>> end-users won't have to use them much, if at all, but they
>
>I can see now gitk should probably be porcelain. But how about
>commands such as git add or git rebase used with either the -i switch
>on or off?
If you have git installed, "man git" should contain separate lists of
porcelain and plumbing. If not, the documentation is available in the git
repository, under Documentation/. Porcelain: cmds-mainporcelain.txt,
cmds-ancillarymanipulators.txt, cmds-ancillaryinterrogators.txt, and
cmds-foreignscminterface.txt. Plumbing: cmds-plumbingmanipulators.txt,
cmds-plumbinginterrogators.txt, cmds-synchingrepositories.txt,
cmds-synchelpers.txt, and cmds-purehelpers.txt
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: what are plumbing and porcelain
From: bill lam @ 2009-01-21 7:23 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: bill lam, git
In-Reply-To: <200901210051.21663.bss@iguanasuicide.net>
Thanks for bringing my attention to that.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩306 鄭畋 馬嵬坡
玄宗回馬楊妃死 雲雨難忘日月新 終是聖明天子事 景陽宮井又何人
^ permalink raw reply
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: Alex Riesen @ 2009-01-21 7:25 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: John Chapman, Hannu Koivisto, rdkrsr, git
In-Reply-To: <alpine.LNX.1.00.0901201833400.19665@iabervon.org>
2009/1/21 Daniel Barkalow <barkalow@iabervon.org>:
> On Wed, 21 Jan 2009, Alex Riesen wrote:
>
>> 2009/1/20 Daniel Barkalow <barkalow@iabervon.org>:
>> > My impression was that this didn't happen in practice, because teams
>> > would tend to not have two people create the same file at the same time,
>> > but with different cases, and people interacting with the same file at
>> > different times would use whatever case it was introduced with.
>>
>> It will and does happen in practice (annoingly too often even). Not with Git
>> yet (with Perforce), where people do "branching" by simply copying things
>> in another directory (perforce world does not know real branches),
>> renaming files randomly, and putting the new directory back in the
>> system (or maybe it is the strange tools here which do that - often
>> it is the first character of a directory or file which gets down- or up-cased).
>
> How does the resulting code work at all? ...
Sometimes it does not. Sometimes it does. Depends on that particular
checkout order perforce (or user?) selected to use this time.
> ... With a case-sensitive filesystem,
> most of the files you're using don't have the expected names any more, and
> most systems will therefore not actually build or run.
Except that there is no case-sensitive file systems on development machines.
So a botched case wont be noticed by a standard build procedure unless
the content of the files causes an error.
>> As Perforce itself is case sensitive (like Git), using of such branches
>> is a nightmare: the files get overwritten in checkout order which is
>> not always sorted in predictable order. Combined with case-stupidity
>> of the file system the working directories sometimes cause "interesting
>> time" for unlucky users.
>> Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with "fanthom"
>> files is rare (it is hard to notice) for most. Which actually makes it more
>> frustrating when the real shit happens.
>>
>> And it will happen to Git as well, especially if development go crossplatform.
>> It is not that hard to accidentally rename a file on case-sensitive file system,
>> "git add *" it and commit without thinking (that's how most of software
>> development happens, come to think of it).
>
> People can accidentally rename files?
Aside from tools (and in my own experience - I did) - they can and do.
> And still have things work when they do it on a case-sensitive filesystem?
Shameless luck, I'd say. That and "no file systems permitted, but the one
from finance dept".
^ permalink raw reply
* read-only working copy using symlinks to blobs
From: chadrik @ 2009-01-21 8:15 UTC (permalink / raw)
To: git
hi all,
i'm looking into using git to manage a lot of very large binary data. git
seems particularly suited to this task because it has features for saving
disk space such as clone--shared, and it's fast due to simple compression by
default (instead of deltas).
in my mind, there's still one major feature for working with large binaries
that has not been addressed: the ability to check out symbolic/hard links
to blobs into the working copy instead of creating duplicates of the files.
imagine a scenario where one user is putting large binary files into a git
repo. 100 other users need read-only access to this repo. they clone the
repo shared, which saves disk space for the object files, but each of these
100 working copies also creates copies of all the binary files at the HEAD
revision. it would be 100x as efficient if, in place of these files,
symbolic or hard links were made to the blob files in .git/objects.
the crux of the issue is that the blob objects would have to be stored as
exact copies of the original files. i did some googling and it would seem
there are two things that currently prevent this from happening. 1) blobs
are stored with compression and 2) they include a small header. compression
can be disabled by setting core.loosecompression to 0, so that seems like
less of an issue. as for the header, wouldn't it be possible to store it as
a separate file per blob object and thus keep the original data completely
pristine?
what are the caveats to a system like this? any thoughts on the
feasibility?
-chad
--
View this message in context: http://www.nabble.com/read-only-working-copy-using-symlinks-to-blobs-tp21578696p21578696.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Add --contains flag to git tag
From: Johannes Schindelin @ 2009-01-21 8:21 UTC (permalink / raw)
To: Jake Goulding; +Cc: Miklos Vajna, git
In-Reply-To: <25058429.247441232510076471.JavaMail.root@scalix.vivisimo.com>
Hi,
On Tue, 20 Jan 2009, Jake Goulding wrote:
> I actually have 1 commit for the code change, one for documentation, and
> one for the test case. Should I squash all these together?
In general, if the patches are not very large and logically belong
together, it is a matter of taste if you squash together documentation and
code changes. Tests, however, belong with the code.
> Also, my test case is in a separate file (t7704-tag-contains.sh) as that
> is how I read t/README. Was this incorrect?
Again, the size matters. If it is a single test case, it is not worth a
whole new file, especially when something like t7004-tag.sh already
exists, whose name just asks for your test case to go in there.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] color-words: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-21 8:25 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901202146.58651.bss@iguanasuicide.net>
Hi,
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> It uses "diff.wordregex" for reasons mention by Dscho and because that
> was already what the diff drivers were using.
To be fair, Jakub and Junio mentioned it, too.
> I'm not entirely satisfied with it. There should probably be some way
> to force the default behavior (which is a bit faster) even if a global
> config or diff driver exists. Also, I think camelCase is better than
> runtogether so I'd prefer to change "wordregex" -> "wordRegex" across
> the entire patch set.
Well, the thing is, it _should_ be "wordRegex", _except_ in the strcmp()
because the config helpers get a downcased key.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Change the spelling of "wordregex".
From: Johannes Schindelin @ 2009-01-21 8:26 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901202259.54886.bss@iguanasuicide.net>
Hi,
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> diff --git a/userdiff.c b/userdiff.c
> index 2b55509..d556da9 100644
> --- a/userdiff.c
> +++ b/userdiff.c
> @@ -6,8 +6,8 @@ static struct userdiff_driver *drivers;
> static int ndrivers;
> static int drivers_alloc;
>
> -#define PATTERNS(name, pattern, wordregex) \
> - { name, NULL, -1, { pattern, REG_EXTENDED }, wordregex }
> +#define PATTERNS(name, pattern, word_regex) \
> + { name, NULL, -1, { pattern, REG_EXTENDED }, word_regex }
> static struct userdiff_driver builtin_drivers[] = {
> PATTERNS("html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$",
> "[^<>= \t]+|[^[:space:]]|[\x80-\xff]+"),
In general, it is an awesomly good idea to imitate code that is already
there. That literally guarantees consistency (which is Good, as you
know).
And Thomas just imitated "xfuncname", which just so happens to be without
an "_".
Ciao,
Dscho
^ permalink raw reply
* how to git a read only directory
From: bill lam @ 2009-01-21 8:33 UTC (permalink / raw)
To: git
I want to use git to keep track of files inside /etc but do not want
to do it as a super user. Is that possible to put GIT_DIR under my
home directory and add public-read files inside /etc? Or that it could
be done in some other ways.
Thanks.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩164 張喬 書邊事
調角斷清秋 征人倚戍樓 春風對青塚 白日落梁州
大漠無兵阻 窮邊有客遊 蕃情似此水 長願向南流
^ permalink raw reply
* Re: how to keeping track of cherry-pick?
From: Knut Olav Bøhmer @ 2009-01-21 8:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vfxjdjvk8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
>
>> svnmerge.py can give us a list of revisions available for merging. The
>> result is similar to "git log --chery-pick master..dev" The difference
>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
>> at the diffs. The result of that is that when we get a conflict when a
>> patch is cherry-picked, it will still show up as "available" when I run
>> "git log --cherry-pick master..dev"
>
> I think you are looking at it a wrong way.
>
> Because subversion (at least the older one) does not keep track of merges,
> you had to track cherry-picks. But cherry-pick is not how you usually do
> things in git. You keep many topic branches with different doneness, and
> you merge well-cooked ones to the more stable integration branch while
> leaving others still cooking. So what you want to know is not cherry-pick
> status, but merge status.
I was afraid I would get this answer. I know that you change your
workflow when you migrate to git, but I was looking for a way to resolve
the situation we are in, due to our old vcs.
--
Knut Olav Bøhmer
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Junio C Hamano @ 2009-01-21 8:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901210113500.19014@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> sha1_name.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 4d10705..803f9d2 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -735,7 +735,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
> if ((target = strstr(match, " to ")) != NULL) {
> len = target - match;
> target += 4;
> - if (target[len] == '\n' && !strncmp(match, target, len))
> + if (len == strlen(target) && !strncmp(match, target, len))
> return 0;
> }
> else
Actually, I think this patch to a884d0c (sha1_name: tweak @{-N} lookup,
2009-01-17) would make more sense.
-- >8 --
Subject: [PATCH] Simplify parsing branch switching events in reflog
We only accept "checkout: moving from A to B" newer style reflog entries,
in order to pick up A. There is no point computing where B begins at
after running strstr to locate " to ", nor adding 4 and then subtracting 4
from the same pointer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
sha1_name.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 38c9f1b..7d95bbb 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -723,17 +723,13 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
if (!prefixcmp(message, "checkout: moving from ")) {
match = message + strlen("checkout: moving from ");
- if ((target = strstr(match, " to ")) != NULL)
- target += 4;
+ target = strstr(match, " to ");
}
if (!match || !target)
return 0;
- len = target - match - 4;
- if (target[len] == '\n' && !strncmp(match, target, len))
- return 0;
-
+ len = target - match;
nth = cb->cnt++ % cb->alloc;
strbuf_reset(&cb->buf[nth]);
strbuf_add(&cb->buf[nth], match, len);
--
1.6.1.281.g16db
^ 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