* [PATCH] Documentation/log: fix description of format.pretty
From: Ramkumar Ramachandra @ 2012-11-11 11:27 UTC (permalink / raw)
To: Git List; +Cc: Jonathan Nieder
59893a88 (Documentation/log: add a CONFIGURATION section, 2010-05-08)
mentioned that `format.pretty` is the default for the `--format`
option. Such an option never existed, and the author meant
`--pretty`. Make this correction.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/git-log.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 585dac4..4b07ad4 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -148,7 +148,7 @@ See linkgit:git-config[1] for core variables and
linkgit:git-
for settings related to diff generation.
format.pretty::
- Default for the `--format` option. (See "PRETTY FORMATS" above.)
+ Default for the `--pretty` option. (See "PRETTY FORMATS" above.)
Defaults to "medium".
i18n.logOutputEncoding::
--
1.7.12.1.428.g652398a.dirty
^ permalink raw reply related
* Re: [PATCH] custom log formats for "diff --submodule=log"
From: Ramkumar Ramachandra @ 2012-11-11 11:26 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jeffrey S. Haemer
In-Reply-To: <20121108202940.GA7982@sigill.intra.peff.net>
Hi Peff,
Jeff King wrote:
> An off-list discussion made me wonder if something like this would be
> useful:
>
> git log -p --submodule=log:' %m %an <%ae>: %s'
>
> where the format could be whatever you find useful.
Interesting. Don't you mean `git diff` in place of `git log -p`
though? I don't think `git log --submodule` does anything differently
from `git log`. Should this respect format.pretty? Does it?
Ram
^ permalink raw reply
* Re: Removing unreachable objects in the presence of broken links?
From: Geert Uytterhoeven @ 2012-11-11 11:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <CAMuHMdU5ZNFs-_TeUE4ntzCCOp85DSOyWMrjJ=yV76MSmjfxDQ@mail.gmail.com>
On Mon, Oct 29, 2012 at 8:56 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Sun, Oct 28, 2012 at 10:34 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>>
>>> Is there a way to force removing unreachable objects in the presence of broken
>>> links?
>>
>> Does it help to forcibly expire the reflogs?
>
> You mean "git reflog expire --all --expire=0"?
>
> After that the reflog is empty, but "git gc" still fails.
Although "git stash list" didn't show anything, .git/refs/stash still contained
one hash.
After running "git stash clear", "git gc" succeeded, and the object pointed to
by .git/refs/stash before was gone.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Reviews on mailing-list
From: suvayu ali @ 2012-11-11 11:11 UTC (permalink / raw)
To: Thiago Farina
Cc: Felipe Contreras, Deniz Türkoglu, Git mailing list,
Junio C Hamano, Shawn Pearce
In-Reply-To: <CACnwZYekU0CYnqQT8L2siJbUsn=T9qowgth94TWc8KN472Ziag@mail.gmail.com>
Hi,
On Sun, Nov 11, 2012 at 2:13 AM, Thiago Farina <tfransosi@gmail.com> wrote:
> On Sat, Nov 10, 2012 at 9:40 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu <deniz@spotify.com> wrote:
>>
>>> This is my first mail to the git mailing list. I have been following
>>> the list for some time now and I would like to suggest moving the
>>> reviews out of the mailing list, for example to a gerrit instance, I
>>> believe it would improve the commits and the mailing list. I have a
>>> filter on 'PATCH', but I feel I miss some of the discussion, and
>>> things that I would be interested in.
>>>
>>> I have spoken to Shawn Pearce (gerrit project lead, google) and he
>>> said he is OK with hosting the gerrit instance.
>>>
>>> I would like to hear your thoughts on this.
>>
>> Personally I think reviews on the mailing list is far superior than
>> any other review methods. I've even blogged about it and all the
>> reasons[1]. Gerrit is better than bugzilla, but it still requires a
>> web browser, and logging in.
>>
> Requiring a web browser is a huge requirement, ham?? How come that can
> be an impediment to move forward way of this awkward way of reviewing
> patches through email? Switching to Gerrit would mean everyone would
> be using the same tool instead of anyone using its own email client
> (gmail, mutt, thunderbird, whatever...) and having to figure out git
> format-patch, git send-email (--reply-to where?).
>
> There are a lot of issues of having to use email for reviewing patches
> that I think Gerrit is a superior alternative.
>
> And many people are arguing for it!
>
> Let's move on...
I'm just a user, I found this discussion intriguing and was wondering if
any of you have heard of patchwork server[1]. It is a patch aggregator
for mailing lists and provides a convenient bug tracker like web
interface without getting in the way of the workflow of reviewing
patches on the mailing list. If you are interested the Org mode
community (an Emacs library) uses it. You can take a look here:
<http://patchwork.newartisans.com/project/org-mode/list/>
I just thought this might be a nice middle ground for people.
Cheers,
Footnotes:
[1] <http://jk.ozlabs.org/projects/patchwork/>
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply
* Re: git-status: Use "-sb" options by default?
From: Ramkumar Ramachandra @ 2012-11-11 10:50 UTC (permalink / raw)
To: Jason Timrod; +Cc: git@vger.kernel.org
In-Reply-To: <1352545457.32390.YahooMailNeo@web160304.mail.bf1.yahoo.com>
Jason Timrod wrote:
> I'm looking for a way to make the "-sb" options to git-status the default somehow.
I've aliased `git status` to `git status -sb` too, and I think it's a
very sensible default; who wants to see
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
over and over again?
Maybe a status.shortWithBranch is in order? However, I don't know if
we can have one configuration option that turns on both `-s` and `-b`.
Ram
^ permalink raw reply
* Re: [PATCH 14/13] test-wildmatch: fix tests that fail on Windows due to path mangling
From: Junio C Hamano @ 2012-11-11 10:47 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King, Johannes Sixt
In-Reply-To: <1352628837-5784-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Patterns beginning with a slash are converted to Windows paths before
> test-wildmatch gets to see them. Avoid this case by always writing
> XXX/abc instead of /abc. The leading XXX will be removed by
> test-wildmatch itself before processing.
>
> Any patterns beginning with a forward slash is rejected by
> test-wildmatch to avoid the same fault in future.
The title taken together with the above explanation makes it sound
as if wildmatch code does not work with the pattern /foo on Windows
at all and to avoid the issue (instead of fixing the breakage) this
patch removes such tests.
But I suspect that is not what is going on. Perhaps the title of the
change is more like "test-wildmatch: avoid Windows path mangling"
and explain with "On Windows, any command line argument that begins
with a slash is mangled as if it were a full pathname. This causes
patterns beginning with a slash not to be passed to test-wildmatch
correctly" or something?
^ permalink raw reply
* [PATCH] contrib/remote-helpers: setup ui.username in test-hg.sh
From: Ramkumar Ramachandra @ 2012-11-11 10:41 UTC (permalink / raw)
To: Git List; +Cc: Felipe Contreras, Jeff King
test-hg.sh forgets to set ui.username, which is required for `hg
commit`. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Squash this into fc/remote-hg in pu?
contrib/remote-helpers/test-hg.sh | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index 40e6e3c..031dcbd 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -29,6 +29,15 @@ check () {
test_cmp expected actual
}
+setup () {
+ (
+ echo "[ui]"
+ echo "username = A U Thor <author@example.com>"
+ ) >> "$HOME"/.hgrc
+}
+
+setup
+
test_expect_success 'cloning' '
test_when_finished "rm -rf gitrepo*" &&
--
1.7.12.1.428.g652398a.dirty
^ permalink raw reply related
* Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: Junio C Hamano @ 2012-11-11 10:33 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann, Nahor
In-Reply-To: <20121110184437.GC2739@mjolnir>
"W. Trevor King" <wking@tremily.us> writes:
> On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote:
>
>> I would not object to "git config submodule.$name.branch $value", on
>> the other hand. "git config" can be used to set a piece of data
>> that has specific meaning, but as a low-level tool, it is not
>> _limited_ to variables that have defined meaning.
>
> This is what I'm doing now:
>
> $ git submodule add -b <branch> <repo> <path>
> $ git config --file .gitmodules submodule.<path>.branch <branch>
> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> With my second patch (Phil's config export), that becomes
>
> $ git submodule add -b <branch> <repo> <path>
> $ git config --file .gitmodules submodule.<path>.branch <branch>
> $ git submodule foreach 'git checkout $submodule_branch && git pull'
>
> With my first patch, that becomes
>
> $ git submodule add -rb <branch> <repo> <path>
> $ git submodule foreach 'git checkout $submodule_branch && git pull'
>
> This seems pretty useful to me,...
Ah, this reminds me of another thing I noticed when I saw that
patch. The change seems to think "branch" is the _only_ thing the
user might want to record per submodule upon "git submodule add".
As an interface to muck with an uninterpreted random configuration,
it squats on a good option name for setting one single and arbitrary
variable---quite a selfish change that is not acceptable.
Calling the option "--record-branch-for-submodule" or something more
specific might alleviate the problem, but then it would become even
less useful as a short-hand for "config submodule.$name.branch", I
would suspect.
On the other hand, if this were one small part of a series to define
the "tip following mode" where (at least)
(1) "git submodule update [$path]" makes sure that the checkout of
the submodule at $path matches the commit at the tip of the
branch named by submodule.$name.branch in .gitmodules of the
superproject, instead of the commit that is recorded in the
index of the superproject; and
(2) "git diff [$path]" and friends in the superproject compares the
HEAD of the checkout of the submodule at $path with the tip of
the branch named by submodule.$name.branch in .gitmodules of
the superproject, instead of the commit that is recorded in the
index of the superproject.
and the option were called something like "--follow-branch=$branch",
it would make much more sense for its initial implementation to set
the name of the branch to submodule.$name.branch variable. Later
iterations of such a feature may want to do more than just setting
that single variable but that is a part of the implementation detail
of the tip following mode the users do not have to know about, just
like setting the submodule.$name.branch variable is.
So in that sense, too, I would be somewhat unhappy to see this
change in the current form to go in.
^ permalink raw reply
* Test failures in contrib/remote-helpers
From: Ramkumar Ramachandra @ 2012-11-11 10:32 UTC (permalink / raw)
To: Git List; +Cc: Felipe Contreras
Hi,
I'm experiencing test failures in contrib/remote-helpers.
>From the first test in test-bzr.sh:
Traceback (most recent call last):
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-bzr",
line 672, in <module>
sys.exit(main(sys.argv))
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-bzr",
line 651, in main
repo = get_repo(url, alias)
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-bzr",
line 608, in get_repo
origin = bzrlib.controldir.ControlDir.open(url)
AttributeError: type object 'ControlDir' has no attribute 'open'
>From the first test in test-hg.sh:
Traceback (most recent call last):
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 785, in <module>
sys.exit(main(sys.argv))
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 773, in main
do_import(parser)
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 500, in do_import
export_head(repo)
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 397, in export_head
export_ref(repo, g_head[0], 'bookmarks', g_head[1])
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 297, in export_ref
revs = repo.revs('%u:%u' % (tip, head))
AttributeError: 'localrepository' object has no attribute 'revs'
fatal: stream ends early
fast-import: dumping crash report to
/home/likewise-open/ANT/ramkum/src/git/t/trash
directory.test-hg/gitrepo/.git/fast_import_crash_24346
fatal: Error while running fast-import
>From the first test in test-hg-bidi.sh:
Traceback (most recent call last):
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 785, in <module>
sys.exit(main(sys.argv))
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 773, in main
do_import(parser)
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 500, in do_import
export_head(repo)
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 397, in export_head
export_ref(repo, g_head[0], 'bookmarks', g_head[1])
File "/home/likewise-open/ANT/ramkum/src/git/contrib/remote-helpers/git-remote-hg",
line 297, in export_ref
revs = repo.revs('%u:%u' % (tip, head))
AttributeError: 'localrepository' object has no attribute 'revs'
fatal: stream ends early
fast-import: dumping crash report to
/home/likewise-open/ANT/ramkum/src/git/t/trash
directory.test-hg-bidi/tmp/gitrepo2/.git/fast_import_crash_25121
fatal: Error while running fast-import
I can't `import hggit` (I don't know how hg-git is distributed), so I
didn't run test-hg-hg-git.sh.
I'm currently investigating.
Ram
^ permalink raw reply
* [PATCH/RFC] attr: allow pattern escape using backslash
From: Nguyễn Thái Ngọc Duy @ 2012-11-11 10:32 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy, Jeff King, Junio C Hamano
.gitattributes pattern syntax is supposed to be the same as .gitignore
(except a few things that do not make sense in attr context, but
that's a different issue). .gitignore uses fnmatch() as the matching
machinery and "\" is accepted as an escape code. In theory the pattern
'foo\ bar' should match path 'foo bar' in .gitignore. Granted, no one
would write 'foo\ bar' in .gitignore when 'foo bar' should
suffice.
Regardless, 'foo\ bar attr' does not (but should) attach "attr" to
path "foo bar" because pattern/attr parse code does not understand
backslash escape. It parses the line as path 'foo\' and attributes
'bar' and 'attr'. This patch teaches attr code to recognize the
backslash in patterns (not macro names) and pass 'foo\ bar' down to
fnmatch().
This changes the attr behavior. "foo\ attr", if exists in the field,
would match nothing because path "foo\" is invalid in UNIX and is a
directory in Windows, which we do not accept attaching attributes
to. With this patch, that line becomes invalid and is rejected. So
it's not really bad (i.e. no silent changes in behavior).
Other subtle behavioral changes may happen. Still, I think we should
do this as it seems like a correct thing to do.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
It was posted [1] during rc cycles (I think) and initial feedback
from Junio was "not utterly wrong". I still think this is worth
doing, hence this resend for discussion.
[1] http://thread.gmane.org/gmane.comp.version-control.git/207135
attr.c | 12 +++++++++++-
t/t0003-attributes.sh | 5 +++++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/attr.c b/attr.c
index 887a9ae..173d51d 100644
--- a/attr.c
+++ b/attr.c
@@ -221,8 +221,18 @@ static struct match_attr *parse_attr_line(const char *line, const char *src,
return NULL;
}
}
- else
+ else {
is_macro = 0;
+ namelen = 0;
+ while (name[namelen] != '\0' &&
+ !strchr(blank, name[namelen])) {
+ if (name[namelen] == '\\' &&
+ name[namelen + 1] != '\0')
+ namelen += 2;
+ else
+ namelen++;
+ }
+ }
states = name + namelen;
states += strspn(states, blank);
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index febc45c..16b419e 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -24,6 +24,7 @@ test_expect_success 'setup' '
echo "offon -test test"
echo "no notest"
echo "A/e/F test=A/e/F"
+ echo "A\\ b test=space"
) >.gitattributes &&
(
echo "g test=a/g" &&
@@ -196,6 +197,10 @@ test_expect_success 'root subdir attribute test' '
attr_check subdir/a/i unspecified
'
+test_expect_success 'quoting in pattern' '
+ attr_check "A b" space
+'
+
test_expect_success 'setup bare' '
git clone --bare . bare.git &&
cd bare.git
--
1.7.12.1.406.g6ab07c4
^ permalink raw reply related
* [PATCH 15/13] compat/fnmatch: fix off-by-one character class's length check
From: Nguyễn Thái Ngọc Duy @ 2012-11-11 10:13 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Sixt,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1352628837-5784-1-git-send-email-pclouds@gmail.com>
Character class "xdigit" is the only one that hits 6 character limit
defined by CHAR_CLASS_MAX_LENGTH. All other character classes are 5
character long and therefore never caught by this.
This should make xdigit tests in t3070 pass on Windows.
Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I tested with Linux (removing the ifdef __LIBC in fnmatch.c) but I
think this should get an ACK from someone who actually uses it on
Windows.
We may want to tell upstream (who?) about this if they haven't fixed
it already.
compat/fnmatch/fnmatch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c
index 9473aed..0ff1d27 100644
--- a/compat/fnmatch/fnmatch.c
+++ b/compat/fnmatch/fnmatch.c
@@ -345,7 +345,7 @@ internal_fnmatch (pattern, string, no_leading_period, flags)
for (;;)
{
- if (c1 == CHAR_CLASS_MAX_LENGTH)
+ if (c1 > CHAR_CLASS_MAX_LENGTH)
/* The name is too long and therefore the pattern
is ill-formed. */
return FNM_NOMATCH;
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH 14/13] test-wildmatch: fix tests that fail on Windows due to path mangling
From: Nguyễn Thái Ngọc Duy @ 2012-11-11 10:13 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Sixt,
Nguyễn Thái Ngọc Duy
In-Reply-To: <5096D76F.5090907@kdbg.org>
Patterns beginning with a slash are converted to Windows paths before
test-wildmatch gets to see them. Avoid this case by always writing
XXX/abc instead of /abc. The leading XXX will be removed by
test-wildmatch itself before processing.
Any patterns beginning with a forward slash is rejected by
test-wildmatch to avoid the same fault in future.
Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On top of nd/wildmatch, apparently.
t/t3070-wildmatch.sh | 10 +++++-----
test-wildmatch.c | 8 ++++++++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index e6ad6f4..3155eab 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -74,7 +74,7 @@ match 0 0 'foo/bar' 'foo[/]bar'
match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 0 'foo' '**/foo'
-match 1 x '/foo' '**/foo'
+match 1 x 'XXX/foo' '**/foo'
match 1 0 'bar/baz/foo' '**/foo'
match 0 0 'bar/baz/foo' '*/foo'
match 0 0 'foo/bar/baz' '**/bar*'
@@ -95,8 +95,8 @@ match 0 0 ']' '[!]-]'
match 1 x 'a' '[!]-]'
match 0 0 '' '\'
match 0 x '\' '\'
-match 0 x '/\' '*/\'
-match 1 x '/\' '*/\\'
+match 0 x 'XXX/\' '*/\'
+match 1 x 'XXX/\' '*/\\'
match 1 1 'foo' 'foo'
match 1 1 '@foo' '@foo'
match 0 0 'foo' '@foo'
@@ -187,8 +187,8 @@ match 0 0 '-' '[[-\]]'
match 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
-match 1 1 '/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
-match 0 0 '/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 74c0864..e384c8e 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -3,6 +3,14 @@
int main(int argc, char **argv)
{
+ int i;
+ for (i = 2; i < argc; i++) {
+ if (argv[i][0] == '/')
+ die("Forward slash is not allowed at the beginning of the\n"
+ "pattern because Windows does not like it. Use `XXX/' instead.");
+ else if (!strncmp(argv[i], "XXX/", 4))
+ argv[i] += 3;
+ }
if (!strcmp(argv[1], "wildmatch"))
return !!wildmatch(argv[3], argv[2], 0);
else if (!strcmp(argv[1], "iwildmatch"))
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: t9350-fast-export.sh broken on peff/pu under Mac OS X
From: Stefano Lattarini @ 2012-11-11 9:32 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Torsten Bögershausen, Git Mailing List
In-Reply-To: <CAMP44s3SSjDqA9cvG9T=-oVH0ADndbxi1MkWF6wR9gxcoCi_xg@mail.gmail.com>
On 11/11/2012 01:58 AM, Felipe Contreras wrote:
>
> It doesn't seem like zsh listens to that variable in sh mode:
> $ zsh -c 'emulate sh; NULLCMD=foobar; > content'
>
Right; "emulate sh" by itself is probably enough today (autoconf, trying
to make its generated scripts extra-portable, tends to accumulate a lot
of cruft unfortunately).
Thanks,
Stefano
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Andreas Schwab @ 2012-11-11 8:58 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: Paul Fox, git
In-Reply-To: <87wqxs4o6f.fsf@Niukka.kon.iki.fi>
Kalle Olavi Niemitalo <kon@iki.fi> writes:
> and neither process blocked any signals (not even SIGCHLD as system(3)
> would).
If you don't have a SIGCHLD handler it won't matter anyway.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Reviews on mailing-list
From: Ramkumar Ramachandra @ 2012-11-11 7:26 UTC (permalink / raw)
To: Deniz Türkoglu; +Cc: git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CA+ZXwZOnZZyk_KWmLLLNChWb1R_Av1s5jM4PsLFWKaG8BB+uXQ@mail.gmail.com>
Deniz Türkoglu wrote:
> I have spoken to Shawn Pearce (gerrit project lead, google) and he
> said he is OK with hosting the gerrit instance.
>
> I would like to hear your thoughts on this.
I personally think email is by far the best interface for patches,
reviews, and discussions. Git patches are very high-volume, and not
everyone can read everything. People should have the flexibility to
choose the client they'd like to use to read patches and follow-ups;
the freedom to use a scriptable client like Gnus is very important to
me. Primarily, I want people to be able to:
1. Choose what to read, by scripting Gnus to score email that they'd
likely find relevant.
2. Try out new patches on the list, by assigning one keybinding to
git-am a series.
3. Display email the way they like. Many email clients have features
to run filters through emails.
4. Read patches/ follow-ups offline, while travelling (on a phone, for
instance). The GMail app, for instance, downloads mails for offline
viewing.
5. Interact with other lists seamlessly (the kernel list, for
instance). Email is a universal interface on which lists can be CC'ed
easily.
I'm not attacking a specific web interface, but I don't see how any of
the following would be possible even with the most advanced web
interface. Besides, nobody has made a proper case for using one.
Therefore, I'm strongly opposed to the move.
Ram
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Kalle Olavi Niemitalo @ 2012-11-11 7:02 UTC (permalink / raw)
To: Paul Fox; +Cc: git
In-Reply-To: <20121110220811.DC6A42E8B68@grass.foxharp.boston.ma.us>
Paul Fox <pgf@foxharp.boston.ma.us> writes:
> you're sending SIGINT to the cvs commit command, and that causes the
> editor to die right away?
That's right. It is not a quirk of shell-mode in Emacs, because
I get the same result with ^C in xterm too.
% EDITOR="$HOME/prefix/x86_64-unknown-linux-gnu/bin/emacsclient --current-frame"
% export EDITOR
% cvs commit BUGIT
Waiting for Emacs...^Ccvs commit: warning: editor session failed
Log message unchanged or not specified
a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs
Action: (continue) a
cvs [commit aborted]: aborted by user
%
While cvs was waiting from emacsclient:
% cat /proc/2030/stat
2030 (cvs) S 1849 2030 1849 34816 2030 4202496 598 0 0 0 0 0 0 0 20 0 1 0 94752537 34254848 410 18446744073709551615 140168182550528 140168183348316 140737407935424 140737407931680 140168163193950 0 0 6 20513 0 0 0 17 2 0 0 0 0 0
% grep 'Name\|Pid\|Sig' /proc/2030/status
Name: cvs
Pid: 2030
PPid: 1849
TracerPid: 0
SigQ: 0/28998
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000006
SigCgt: 0000000180005021
% cat /proc/2031/stat
2031 (emacsclient) S 2030 2030 1849 34816 2030 4202496 155 0 0 0 0 0 0 0 20 0 1 0 94752538 4169728 81 18446744073709551615 4194304 4210620 140735996104016 140735996095456 140664960886018 0 0 0 0 0 0 0 17 1 0 0 0 0 0
% grep 'Name\|Pid\|Sig' /proc/2031/status
Name: emacsclient
Pid: 2031
PPid: 2030
TracerPid: 0
SigQ: 0/28998
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
%
which I interpret to mean both processes were in process group
2030, the cvs process ignored SIGINT and SIGQUIT, the emacsclient
process neither ignored nor handled any signals, and neither
process blocked any signals (not even SIGCHLD as system(3) would).
When ^C in the terminal sent SIGINT to the process group, it
terminated the emacsclient process only.
If git did the same thing as cvs here, i.e. ignore the signals in
the parent process only and check the exit status of the editor,
I think that would be OK.
^ permalink raw reply
* Re: Reviews on mailing-list
From: Junio C Hamano @ 2012-11-11 5:54 UTC (permalink / raw)
To: Thiago Farina, Felipe Contreras; +Cc: Deniz Türkoglu, git, Shawn Pearce
In-Reply-To: <CACnwZYekU0CYnqQT8L2siJbUsn=T9qowgth94TWc8KN472Ziag@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> wrote:
>Requiring a web browser is a huge requirement, ham??
No, but requiring reviews and discussions typed in the browser is.
Pardon terseness, typo and HTML from a tablet.
^ permalink raw reply
* [PATCH] gitweb: git_summary - show $project in title
From: Henrich Schuchardt @ 2012-11-11 5:20 UTC (permalink / raw)
To: git; +Cc: xypron.glpk
Gitweb pages are structured by divs of class title with grey background.
The shortlog, and the log page show the project name as the first title.
Page summary only shows an empty grey box above the project details.
This provides an inconstent user experience.
This patch adds the missing project title.
Signed-off-by: Henrich Schuchardt <xypron.glpk@gmx.de>
---
gitweb/gitweb.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10ed9e5..3e1c452 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6451,7 +6451,7 @@ sub git_summary {
git_header_html();
git_print_page_nav('summary','', $head);
- print "<div class=\"title\"> </div>\n";
+ print "<div class=\"title\">$project</div>\n";
print "<table class=\"projects_list\">\n" .
"<tr id=\"metadata_desc\"><td>description</td><td>" . esc_html($descr) . "</td></tr>\n";
unless ($omit_owner) {
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v4 3/6] Color skipped tests blue
From: Adam Spiers @ 2012-11-11 2:04 UTC (permalink / raw)
To: Jeff King; +Cc: git list, Junio C Hamano, Stefano Lattarini
In-Reply-To: <20120921061325.GA15867@sigill.intra.peff.net>
On Fri, Sep 21, 2012 at 02:13:25AM -0400, Jeff King wrote:
> On Wed, Sep 19, 2012 at 09:24:23PM +0100, Adam Spiers wrote:
>
> > t/test-lib.sh | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 5293830..78c88c2 100755
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -182,13 +182,13 @@ then
> > error)
> > tput bold; tput setaf 1;; # bold red
> > skip)
> > - tput bold; tput setaf 2;; # bold green
> > + tput setaf 4;; # blue
> > warn)
> > tput bold; tput setaf 3;; # bold yellow
> > pass)
> > tput setaf 2;; # green
> > info)
> > - tput setaf 3;; # brown
> > + tput setaf 3;; # yellow/brown
>
> I happened to be running a test script with "-v" earlier today, and I
> noticed that the "expecting success..." dump of the test contents is
> also yellow. By your new rules, shouldn't it be blue?
>
> I think it is matching the "info" type, which from the discussion should
> be blue, no?
It uses the "default" colour:
say >&3 "expecting success: $2"
where say is defined:
say () {
say_color info "$*"
}
Many other messages are output in this default colour too, and I never
proposed to change it. The only time in the discussion where blue was
associated with "info" was in this sentence I wrote in the
commit message for the patch altering the colour of "skip" messages:
"However, it's more informational than cautionary, so instead we
use blue which is a universal color for information signs."
Whilst it could also be applied to "info", I don't think it would be a
good idea to have the "skip" and "info" colours *both* as bold blue.
It seems to me more important that the "skip" messages should visually
stand out more than "info", since they are rarer and a more notable
level of information than the latter (especially if --verbose is
used). Additionally, yellow is already somewhat overloaded (yellow
for "info" and bold yellow for "warn"). Therefore I would suggest
changing "info" to perhaps bold white or bold cyan. Or "skip" could
be magenta and "info" blue. But now we are heading down a slippery
slope; it'll be near impossible to please everyone. Any final
thoughts?
> Maybe it is just my terminal. I see it is labeled as "brown" here, but
> it looks very yellow (and I am using the stock xterm colors. According
> to:
>
> https://en.wikipedia.org/wiki/ANSI_colors
>
> It looks it really is brown on some platforms.
Yes, it can be.
> I'm not sure if it is
> worth worrying about. I don't really want to get into configurable
> colors just for the test-suite output.
Agreed. There is no indisputably correct combination. However, I
think that, modulo a tweak for the above, we are definitely in the
right ball park. The main thing is that the traffic light colour
scheme is adhered to, and that different types of message are clearly
visually separated, with more important ones standing out more than
less important ones.
^ permalink raw reply
* Re: Reviews on mailing-list
From: Deniz Türkoglu @ 2012-11-11 1:28 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CAMP44s2AvaAs-dn_eoSFWoLHBQk5QrrV=zYTOpRi2nEywoua4w@mail.gmail.com>
On Sat, Nov 10, 2012 at 3:40 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu <deniz@spotify.com> wrote:
>
>> This is my first mail to the git mailing list. I have been following
>> the list for some time now and I would like to suggest moving the
>> reviews out of the mailing list, for example to a gerrit instance, I
>> believe it would improve the commits and the mailing list. I have a
>> filter on 'PATCH', but I feel I miss some of the discussion, and
>> things that I would be interested in.
>>
>> I have spoken to Shawn Pearce (gerrit project lead, google) and he
>> said he is OK with hosting the gerrit instance.
>>
>> I would like to hear your thoughts on this.
>
> Personally I think reviews on the mailing list is far superior than
> any other review methods. I've even blogged about it and all the
> reasons[1]. Gerrit is better than bugzilla, but it still requires a
> web browser, and logging in.
I disagree that the current approach is optimal. Bugzilla is a
bug-tracker and is not meant to be used for reviews. I believe in
using the right tool for the right job. An e-mail should be concise
and to the point, in this case only contain the discussion. This will
help it to reach a wider audience and be more useful when people
stumble upon it through a google search.
cheers,
-deniz
^ permalink raw reply
* Re: Reviews on mailing-list
From: Thiago Farina @ 2012-11-11 1:13 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Deniz Türkoglu, git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CAMP44s2AvaAs-dn_eoSFWoLHBQk5QrrV=zYTOpRi2nEywoua4w@mail.gmail.com>
On Sat, Nov 10, 2012 at 9:40 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu <deniz@spotify.com> wrote:
>
>> This is my first mail to the git mailing list. I have been following
>> the list for some time now and I would like to suggest moving the
>> reviews out of the mailing list, for example to a gerrit instance, I
>> believe it would improve the commits and the mailing list. I have a
>> filter on 'PATCH', but I feel I miss some of the discussion, and
>> things that I would be interested in.
>>
>> I have spoken to Shawn Pearce (gerrit project lead, google) and he
>> said he is OK with hosting the gerrit instance.
>>
>> I would like to hear your thoughts on this.
>
> Personally I think reviews on the mailing list is far superior than
> any other review methods. I've even blogged about it and all the
> reasons[1]. Gerrit is better than bugzilla, but it still requires a
> web browser, and logging in.
>
Requiring a web browser is a huge requirement, ham?? How come that can
be an impediment to move forward way of this awkward way of reviewing
patches through email? Switching to Gerrit would mean everyone would
be using the same tool instead of anyone using its own email client
(gmail, mutt, thunderbird, whatever...) and having to figure out git
format-patch, git send-email (--reply-to where?).
There are a lot of issues of having to use email for reviewing patches
that I think Gerrit is a superior alternative.
And many people are arguing for it!
Let's move on...
^ permalink raw reply
* Re: t9350-fast-export.sh broken on peff/pu under Mac OS X
From: Felipe Contreras @ 2012-11-11 0:58 UTC (permalink / raw)
To: Stefano Lattarini
Cc: Junio C Hamano, Torsten Bögershausen, Git Mailing List
In-Reply-To: <509EEF09.6060109@gmail.com>
On Sun, Nov 11, 2012 at 1:19 AM, Stefano Lattarini
<stefano.lattarini@gmail.com> wrote:
> On 11/11/2012 12:11 AM, Felipe Contreras wrote:
>> On Sat, Nov 10, 2012 at 11:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> On Sat, Nov 10, 2012 at 3:37 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>>>> The short version:
>>>>> echo -n doesn't seem to be portable.
>>>>> The following works for me:
>>>>
>>>> Right, I was supposed to change that to:
>>>>
>>>> true > marks-cur &&
>>>
>>> Please make it like so:
>>>
>>> >marks-cur &&
>>>
>>> No command is necessary when creating an empty file or truncating an
>>> existing file to empty, and no SP between redirection and its target.
>>
>> That hangs on zsh (presumably waiting for stdin).
>>
> Unless you set:
>
> NULLCMD=:
>
> early in your test script.
>
> Or, to be extra-safe, you could steal this initialization code from
> autoconf:
>
> # Be more Bourne compatible.
> if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
> emulate sh
> NULLCMD=:
> setopt NO_GLOB_SUBST
> # Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
> # is contrary to our usage. Disable this feature.
> alias -g '${1+"$@"}'='"$@"'
It doesn't seem like zsh listens to that variable in sh mode:
% zsh -c 'emulate sh; NULLCMD=foobar; > content'
And it doesn't seem like NO_GLOB_SUBST is needed any more.
I think it doesn't hurt to do 'true > marks-cur', but whatever.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: orphan blob or what?
From: bruce @ 2012-11-11 0:32 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <1352497275-ner-6808@calvin>
Tomas Carnecky <tomas.carnecky@gmail.com> writes:
> On Fri, 09 Nov 2012 11:37:04 -0800, bruce <bruce.e.robertson@intel.com> wrote:
>> Tomas Carnecky <tomas.carnecky@gmail.com> writes:
>>
>> Just idiocy on my part. Thanks.
>>
>> > On Thu, 08 Nov 2012 16:24:36 -0800, bruce <bruce.e.robertson@intel.com> wrote:
>> >> In today's and older clones of https://github.com/mirrors/linux.git I
>> >> find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't
>> >> figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it
>> >> in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it,
>> >> can't see it via 'git log'. And yet
>> >>
>> >> linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee
>> >> 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673
>> >> 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
>> >> f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
>> >
>> > Commit dee0bb9 (ASoC: Mark WM8962 Additional Control 4 register as volatile,
>> > 2010-09-29) references this blob.
>
> It wasn't easy to find the commit. First I figured out at which path that file
> was stored. Using git log -S'wm8962_reg[WM8962_MAX_REGISTER + 1]' I quickly
> determined that the file was somewhere in sound/, more specifically
> sound/soc/codecs/wm8962-tables.c. However a 'git log --
> sound/soc/codecs/wm8962-tables.c' did not show any commit. That was strange,
> because 'git log -S'WM8962_MAX_REGISTER + 1' --name-status --
> sound/soc/codecs/' clearly shows that the file existed at some point in the
> past. The commit is hidden from a simple 'git log' due to 'History
> Simplification'. See the git-log man page. I added --full-history -p to the log
> command, and searched in the pager for '6fa98e'. That revealed the commit which
> references that blob:
>
> git log --full-history -p -- sound/soc/codecs/wm8962-tables.c
Thanks very much for the elucidation. I really must RTFMs. Only 44.786
Kib lines. Porcelain (mostly) first. I just can't eliminate the reading
I need to do.
FWIW, I was somewhat perplexed by searching for
c969f19f8fd17e600a16fe91aab66d86936cce0a in 'gitk -all'. It doesn't find
it BUT if I use --select-commit=c969f19f8fd17e600a16fe91aab66d86936cce0a
then positions to it. If I position away again it again can't find
it. Bother!
BTW, this was all occasioned by looking for unused large packed blobs as
an educational exercise.
Thanks again,
Bruce
^ permalink raw reply
* Re: t9350-fast-export.sh broken on peff/pu under Mac OS X
From: Stefano Lattarini @ 2012-11-11 0:19 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Torsten Bögershausen, Git Mailing List
In-Reply-To: <CAMP44s0dQ8EeCkHo8Lh3odG3qQoeLFModec+7doLeTHnZoJ_pg@mail.gmail.com>
On 11/11/2012 12:11 AM, Felipe Contreras wrote:
> On Sat, Nov 10, 2012 at 11:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> On Sat, Nov 10, 2012 at 3:37 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>>> The short version:
>>>> echo -n doesn't seem to be portable.
>>>> The following works for me:
>>>
>>> Right, I was supposed to change that to:
>>>
>>> true > marks-cur &&
>>
>> Please make it like so:
>>
>> >marks-cur &&
>>
>> No command is necessary when creating an empty file or truncating an
>> existing file to empty, and no SP between redirection and its target.
>
> That hangs on zsh (presumably waiting for stdin).
>
Unless you set:
NULLCMD=:
early in your test script.
Or, to be extra-safe, you could steal this initialization code from
autoconf:
# Be more Bourne compatible.
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
emulate sh
NULLCMD=:
setopt NO_GLOB_SUBST
# Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
# is contrary to our usage. Disable this feature.
alias -g '${1+"$@"}'='"$@"'
else
case `(set -o) 2>/dev/null` in *posix*) set -o posix ;; esac
fi
All of this untested with the real Git testsuite, of course ;-)
Regards, and HTH,
Stefano
^ permalink raw reply
* [PATCH] git-credential-gnome-keyring: Remove die
From: Matt Kraai @ 2012-11-11 0:08 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
git-credential-gnome-keyring defines die, but it is unused and
incorrect (it passes a va_list to error, which does not expect one),
so remove it.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
.../credential/gnome-keyring/git-credential-gnome-keyring.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 41f61c5..3eaafba 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -104,16 +104,6 @@ static inline void error(const char *fmt, ...)
va_end(ap);
}
-static inline void die(const char *fmt, ...)
-{
- va_list ap;
-
- va_start(ap,fmt);
- error(fmt, ap);
- va_end(ap);
- exit(EXIT_FAILURE);
-}
-
static inline void die_errno(int err)
{
error("%s", strerror(err));
--
1.7.10.4
^ 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