* Re: [PATCH 1/2] api-parse-options.txt: Introduce documentation for parse options API
From: Michele Ballabio @ 2008-06-22 12:49 UTC (permalink / raw)
To: git; +Cc: Stephan Beyer, Pierre Habouzit, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <1214092802-8175-1-git-send-email-s-beyer@gmx.net>
On Sunday 22 June 2008, Stephan Beyer wrote:
> +`PARSE_OPT_KEEP_DASHDASH`::
> + Usually long options (`\--long-opt`) are boiled down to their
> + short option equivalent, if available.
> + Using this flag, long options are kept.
No: PARSE_OPT_KEEP_DASHDASH keeps the "--" that usually separates options
from files, as in
git ls-files [options] -- [files]
i.e. after parsing, the new argv will still contain "--".
> +`OPT__ABBREV(&int_var)`::
> + Add `\--abbrev [<n>]`.
better:
+ Add `\--abbrev[=<n>]`.
since the <n> is optional.
^ permalink raw reply
* git log --follow <filename> doesn't follow across 'subtree strategy' merge
From: Jakub Narebski @ 2008-06-22 12:51 UTC (permalink / raw)
To: git
When trying to see all history of gitweb using
$ git log -C -C --raw --abbrev --follow gitweb/gitweb.perl
I have noticed that while it correctly detects renaming
gitweb/gitweb.cgi to gitweb/gitweb.perl, and follows this rename, it
cannot get past merge commit 0a8f4f0020cb35095005852c0797f0b90e9ebb74
and follow moving gitweb.cgi to gitweb/gitweb.cgi.
To get full history I have to use
$ git log -C -C --raw -- gitweb/gitweb.perl gitweb/gitweb.cgi \
gitweb.cgi
Adding '--full-history' doesn't help...
--
Jakub Narebski
Thorn, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: linux-x86-tip: pilot error?
From: Mikael Magnusson @ 2008-06-22 12:48 UTC (permalink / raw)
To: paulmck; +Cc: mingo, git
In-Reply-To: <20080622123620.GA9328@linux.vnet.ibm.com>
2008/6/22 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> Hello, Ingo,
>
> I took the precaution of rebuilding my linux-2.6-tip from scratch as follows:
>
> 544 mkdir linux-2.6-tip
> 545 cd linux-2.6-tip
> 546 git-init-db
> 547 git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 548 git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
> 549 git-remote update
> 550 git-checkout tip-core-rcu-2008-06-16_09.23_Mon
When checking out remote branches, you have to specify the remote:
git checkout tip/tip-blabla
(it'll warn about detaching HEAD, this is normal).
--
Mikael Magnusson
^ permalink raw reply
* Re: linux-x86-tip: pilot error?
From: Paul E. McKenney @ 2008-06-22 13:21 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: mingo, git
In-Reply-To: <237967ef0806220548t3fd73211v354071efe2db22e4@mail.gmail.com>
On Sun, Jun 22, 2008 at 02:48:35PM +0200, Mikael Magnusson wrote:
> 2008/6/22 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> > Hello, Ingo,
> >
> > I took the precaution of rebuilding my linux-2.6-tip from scratch as follows:
> >
> > 544 mkdir linux-2.6-tip
> > 545 cd linux-2.6-tip
> > 546 git-init-db
> > 547 git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > 548 git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
> > 549 git-remote update
> > 550 git-checkout tip-core-rcu-2008-06-16_09.23_Mon
>
> When checking out remote branches, you have to specify the remote:
> git checkout tip/tip-blabla
> (it'll warn about detaching HEAD, this is normal).
Thank you, Mikael!
But when I try "git-checkout tip/tip-core-rcu-2008-06-16_09.23_Mon",
it says:
error: pathspec 'tip/tip-core-rcu-2008-06-16_09.23_Mon' did not match any file(s) known to git.
Did you forget to 'git add'?
Trying "git-checkout tip/tip-core-rcu" gets me:
error: pathspec 'tip/tip-core-rcu' did not match any file(s) known to git.
Did you forget to 'git add'?
Trying "git-checkout -b tip-core-rcu tip/tip-core-rcu" gets me:
git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'tip/tip-core-rcu' which can not be resolved as commit?
Trying "git-checkout -b tip-core-rcu tip/tip-core-rcu-2008-06-16_09.23_Mon"
gets me:
git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'tip/tip-core-rcu-2008-06-16_09.23_Mon' which can not be resolved as commit?
Trying "git-checkout -b tip-core-rcu tip-core-rcu-2008-06-16_09.23_Mon"
acts like it is doing something useful, but doesn't find the recent updates,
which I believe happened -before- June 16 2008.
Help???
Thanx, Paul
^ permalink raw reply
* Re: "git-pull --no-commit" should imply --no-ff...?
From: Graham Wilson @ 2008-06-22 13:36 UTC (permalink / raw)
To: Stefan Richter; +Cc: git
In-Reply-To: <tkrat.5aa5af8e9968819c@s5r6.in-berlin.de>
On Sat, Jun 21, 2008 at 04:08:51PM +0200, Stefan Richter wrote:
> trying "git pull --no-commit . foo" for the first time, I was confused
> that --no-commit was a no-op when the pull resulted in a fast-forward.
> I.e. HEAD advanced the whole chain of commits to foo. I expected it to
> apply the diff of HEAD..foo but not commit them.
--no-commit to me seems to mean don't commit a merge commit. Maybe what
you want is something like:
git-diff HEAD foo | git-apply
--
gram
^ permalink raw reply
* Re: [PATCH 1/2] api-parse-options.txt: Introduce documentation for parse options API
From: Stephan Beyer @ 2008-06-22 13:45 UTC (permalink / raw)
To: Michele Ballabio
Cc: git, Pierre Habouzit, Junio C Hamano, Johannes Schindelin
In-Reply-To: <200806221449.08307.barra_cuda@katamail.com>
> > +`PARSE_OPT_KEEP_DASHDASH`::
> > + Usually long options (`\--long-opt`) are boiled down to their
> > + short option equivalent, if available.
> > + Using this flag, long options are kept.
>
> No: PARSE_OPT_KEEP_DASHDASH keeps the "--" that usually separates options
> from files, as in
Eh, right, of course! What I wrote doesn't make any sense. ;-)
> > +`OPT__ABBREV(&int_var)`::
> > + Add `\--abbrev [<n>]`.
>
> better:
> + Add `\--abbrev[=<n>]`.
>
> since the <n> is optional.
That's right and I also expected that print_usage_with_options() would
do so, since the other variant is ambiguous, BUT:
$ ./test-parse-options -h 2>&1 | grep abbrev
--abbrev [<n>] use <n> digits to display SHA-1s
And I didn't want to change parse-options.c ;-)
Any other comments?
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: "git-pull --no-commit" should imply --no-ff...?
From: Miklos Vajna @ 2008-06-22 13:49 UTC (permalink / raw)
To: Stefan Richter, git
In-Reply-To: <20080622133606.GA21828@endor.mknod.org>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Sun, Jun 22, 2008 at 08:36:06AM -0500, Graham Wilson <graham@mknod.org> wrote:
> On Sat, Jun 21, 2008 at 04:08:51PM +0200, Stefan Richter wrote:
> > trying "git pull --no-commit . foo" for the first time, I was confused
> > that --no-commit was a no-op when the pull resulted in a fast-forward.
> > I.e. HEAD advanced the whole chain of commits to foo. I expected it to
> > apply the diff of HEAD..foo but not commit them.
>
> --no-commit to me seems to mean don't commit a merge commit. Maybe what
> you want is something like:
>
> git-diff HEAD foo | git-apply
Or git merge --no-commit --squash?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Exec format error when using gitweb
From: Erez Zilber @ 2008-06-22 13:51 UTC (permalink / raw)
To: git
Hi,
I'm trying to config gitweb using v1.5.5.3. I'm able to see my
repositories (through gitweb) but I see the following errors in
/var/log/httpd/error_log. Can anyone help?
[Sun Jun 22 16:33:53 2008] [error] [client 172.16.0.7] (8)Exec format
error: exec of '/var/www/cgi-bin/gitweb/gitweb.css' failed, referer:
http://kites/cgi-bin/gitweb/gitweb.cgi
[Sun Jun 22 16:33:53 2008] [error] [client 172.16.0.7] Premature end
of script headers: gitweb.css, referer:
http://kites/cgi-bin/gitweb/gitweb.cgi
[Sun Jun 22 16:33:53 2008] [error] [client 172.16.0.7] (8)Exec format
error: exec of '/var/www/cgi-bin/gitweb/git-logo.png' failed, referer:
http://kites/cgi-bin/gitweb/gitweb.cgi
[Sun Jun 22 16:33:53 2008] [error] [client 172.16.0.7] Premature end
of script headers: git-logo.png, referer:
http://kites/cgi-bin/gitweb/gitweb.cgi
Thanks,
Erez
^ permalink raw reply
* Re: "git-pull --no-commit" should imply --no-ff...?
From: Stefan Richter @ 2008-06-22 14:01 UTC (permalink / raw)
To: git
In-Reply-To: <20080622133606.GA21828@endor.mknod.org>
Graham Wilson wrote:
> On Sat, Jun 21, 2008 at 04:08:51PM +0200, Stefan Richter wrote:
>> trying "git pull --no-commit . foo" for the first time, I was confused
>> that --no-commit was a no-op when the pull resulted in a fast-forward.
>> I.e. HEAD advanced the whole chain of commits to foo. I expected it to
>> apply the diff of HEAD..foo but not commit them.
>
> --no-commit to me seems to mean don't commit a merge commit. Maybe what
> you want is something like:
>
> git-diff HEAD foo | git-apply
>
Yes, I obviously got the wrong idea about git-pull --no-commit.
git-diff + git-apply indeed accomplishes what I wanted to do. Thanks,
--
Stefan Richter
-=====-==--- -==- =-==-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Exec format error when using gitweb
From: Lea Wiemann @ 2008-06-22 14:04 UTC (permalink / raw)
To: Erez Zilber; +Cc: git
In-Reply-To: <ce513bcc0806220651g5cf59516w3fc30a68d7f09e79@mail.gmail.com>
Erez Zilber wrote:
> [Sun Jun 22 16:33:53 2008] [error] [client 172.16.0.7] (8)Exec format
> error: exec of '/var/www/cgi-bin/gitweb/gitweb.css' failed, referer:
Random guess: Did you make the data files (.css, .png) executable by
accident, so your server is trying to execute them?
-- Lea
^ permalink raw reply
* [PATCH] git-rebase.sh: Add check if rebase is in progress
From: Stephan Beyer @ 2008-06-22 14:07 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Git Mailing List, Junio C Hamano, Stephan Beyer
In-Reply-To: <485DC551.9020807@gmail.com>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
git-rebase.sh | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index dd7dfe1..74f9c25 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -150,6 +150,9 @@ while test $# != 0
do
case "$1" in
--continue)
+ test -d "$dotest" -o -d .dotest ||
+ die "No rebase in progress?"
+
git diff-files --quiet --ignore-submodules || {
echo "You must edit all merge conflicts and then"
echo "mark them as resolved using git add"
@@ -178,6 +181,9 @@ do
exit
;;
--skip)
+ test -d "$dotest" -o -d .dotest ||
+ die "No rebase in progress?"
+
git reset --hard HEAD || exit $?
if test -d "$dotest"
then
@@ -203,16 +209,16 @@ do
exit
;;
--abort)
+ test -d "$dotest" -o -d .dotest ||
+ die "No rebase in progress?"
+
git rerere clear
if test -d "$dotest"
then
move_to_original_branch
- elif test -d .dotest
- then
+ else
dotest=.dotest
move_to_original_branch
- else
- die "No rebase in progress?"
fi
git reset --hard $(cat "$dotest/orig-head")
rm -r "$dotest"
--
1.5.6.310.g344d
^ permalink raw reply related
* Re: Exec format error when using gitweb
From: Erez Zilber @ 2008-06-22 14:11 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <485E5BD6.6060105@gmail.com>
On Sun, Jun 22, 2008 at 5:04 PM, Lea Wiemann <lewiemann@gmail.com> wrote:
> Erez Zilber wrote:
>>
>> [Sun Jun 22 16:33:53 2008] [error] [client 172.16.0.7] (8)Exec format
>> error: exec of '/var/www/cgi-bin/gitweb/gitweb.css' failed, referer:
>
> Random guess: Did you make the data files (.css, .png) executable by
> accident, so your server is trying to execute them?
>
Thanks for the quick response. Yeah, I did that after I got
"Permission denied" errors. Now, I chnaged it and it looks like this:
[admin@kites ~]$ sudo ls -l /var/www/cgi-bin/gitweb
total 192
-rwxr-xr-x 1 apache root 164 Jun 19 13:57 git-favicon.png
-rw-r--r-- 1 apache root 208 Jun 19 13:57 git-logo.png
-rwxr-xr-x 1 apache root 170562 Jun 19 13:57 gitweb.cgi
-rwxr-xr-x 1 apache root 79 Jun 22 16:29 gitweb_config.perl
-rw-r--r-- 1 apache root 7112 Jun 19 13:57 gitweb.css
and I get the following errors:
[Sun Jun 22 17:06:08 2008] [error] [client 172.16.0.7] (13)Permission
denied: exec of '/var/www/cgi-bin/gitweb/gitweb.css' failed, referer:
http://kites/cgi-bin/gitweb/gitweb.cgi
[Sun Jun 22 17:06:08 2008] [error] [client 172.16.0.7] Premature end
of script headers: gitweb.css, referer:
http://kites/cgi-bin/gitweb/gitweb.cgi
[Sun Jun 22 17:06:08 2008] [error] [client 172.16.0.7] (13)Permission
denied: exec of '/var/www/cgi-bin/gitweb/git-logo.png' failed,
referer: http://kites/cgi-bin/gitweb/gitweb.cgi
[Sun Jun 22 17:06:08 2008] [error] [client 172.16.0.7] Premature end
of script headers: git-logo.png, referer:
http://kites/cgi-bin/gitweb/gitweb.cgi
Erez
^ permalink raw reply
* Re: Exec format error when using gitweb
From: Lea Wiemann @ 2008-06-22 14:17 UTC (permalink / raw)
To: Erez Zilber; +Cc: git
In-Reply-To: <ce513bcc0806220711k5e8c5085qfa330b017d736142@mail.gmail.com>
Erez Zilber wrote:
> -rw-r--r-- 1 apache root 7112 Jun 19 13:57 gitweb.css
>
> [Sun Jun 22 17:06:08 2008] [error] [client 172.16.0.7] (13)Permission
> denied: exec of '/var/www/cgi-bin/gitweb/gitweb.css' failed, referer:
Apparently your web server is trying to execute gitweb.css even though
its executable bit isn't set -- perhaps because it's located in the
cgi-bin directory. I suggest you open
http://.../cgi-bin/gitweb/gitweb.css and try to get it to display the
CSS file in your browser; this is a problem with your web server, not
with gitweb.
(By the way, git-favicon.png and gitweb_config.perl shouldn't have their
executable bits set either, since they're not CGI scripts.)
-- Lea
^ permalink raw reply
* [PATCH] parse-options.c: fix documentation syntax of optional arguments
From: Michele Ballabio @ 2008-06-22 14:39 UTC (permalink / raw)
To: git; +Cc: Stephan Beyer, Pierre Habouzit, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <20080622134550.GA5279@leksak.fem-net>
When an argument for an option is optional, short options don't need a
space between the option and the argument, and long options need a "=".
Otherwise, arguments are misinterpreted.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
On Sunday 22 June 2008, Stephan Beyer wrote:
> > > +`OPT__ABBREV(&int_var)`::
> > > + Add `\--abbrev [<n>]`.
> >
> > better:
> > + Add `\--abbrev[=<n>]`.
> >
> > since the <n> is optional.
>
> That's right and I also expected that print_usage_with_options() would
> do so, since the other variant is ambiguous, BUT:
>
> $ ./test-parse-options -h 2>&1 | grep abbrev
> --abbrev [<n>] use <n> digits to display SHA-1s
>
> And I didn't want to change parse-options.c ;-)
Here it is.
parse-options.c | 15 ++++++++++++---
t/t1502-rev-parse-parseopt.sh | 2 +-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index acf3fe3..f8d52e2 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -344,7 +344,10 @@ void usage_with_options_internal(const char * const *usagestr,
break;
case OPTION_INTEGER:
if (opts->flags & PARSE_OPT_OPTARG)
- pos += fprintf(stderr, "[<n>]");
+ if (opts->long_name)
+ pos += fprintf(stderr, "[=<n>]");
+ else
+ pos += fprintf(stderr, "[<n>]");
else
pos += fprintf(stderr, " <n>");
break;
@@ -355,12 +358,18 @@ void usage_with_options_internal(const char * const *usagestr,
case OPTION_STRING:
if (opts->argh) {
if (opts->flags & PARSE_OPT_OPTARG)
- pos += fprintf(stderr, " [<%s>]", opts->argh);
+ if (opts->long_name)
+ pos += fprintf(stderr, "[=<%s>]", opts->argh);
+ else
+ pos += fprintf(stderr, "[<%s>]", opts->argh);
else
pos += fprintf(stderr, " <%s>", opts->argh);
} else {
if (opts->flags & PARSE_OPT_OPTARG)
- pos += fprintf(stderr, " [...]");
+ if (opts->long_name)
+ pos += fprintf(stderr, "[=...]");
+ else
+ pos += fprintf(stderr, "[...]");
else
pos += fprintf(stderr, " ...");
}
diff --git a/t/t1502-rev-parse-parseopt.sh b/t/t1502-rev-parse-parseopt.sh
index d24a47d..3508d0a 100755
--- a/t/t1502-rev-parse-parseopt.sh
+++ b/t/t1502-rev-parse-parseopt.sh
@@ -13,7 +13,7 @@ usage: some-command [options] <args>...
--bar ... some cool option --bar with an argument
An option group Header
- -C [...] option C with an optional argument
+ -C[...] option C with an optional argument
Extras
--extra1 line above used to cause a segfault but no longer does
--
1.5.6
^ permalink raw reply related
* Re: Exec format error when using gitweb
From: Luciano Rocha @ 2008-06-22 14:42 UTC (permalink / raw)
To: Erez Zilber; +Cc: git
In-Reply-To: <ce513bcc0806220651g5cf59516w3fc30a68d7f09e79@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
On Sun, Jun 22, 2008 at 04:51:52PM +0300, Erez Zilber wrote:
> Hi,
>
> I'm trying to config gitweb using v1.5.5.3. I'm able to see my
> repositories (through gitweb) but I see the following errors in
> /var/log/httpd/error_log. Can anyone help?
>
> [Sun Jun 22 16:33:53 2008] [error] [client 172.16.0.7] (8)Exec format
> error: exec of '/var/www/cgi-bin/gitweb/gitweb.css' failed, referer:
> http://kites/cgi-bin/gitweb/gitweb.cgi
If cgi-bin is configured as ScriptAlias in Apache httpd server, then it
will try to execute every file inside that directory. You should move
them elsewere, or use a different directory altogether, with ExecCGI
permissions.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Exec format error when using gitweb
From: Erez Zilber @ 2008-06-22 14:47 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <485E5EDF.1030002@gmail.com>
On Sun, Jun 22, 2008 at 5:17 PM, Lea Wiemann <lewiemann@gmail.com> wrote:
> Erez Zilber wrote:
>>
>> -rw-r--r-- 1 apache root 7112 Jun 19 13:57 gitweb.css
>>
>> [Sun Jun 22 17:06:08 2008] [error] [client 172.16.0.7] (13)Permission
>> denied: exec of '/var/www/cgi-bin/gitweb/gitweb.css' failed, referer:
>
> Apparently your web server is trying to execute gitweb.css even though its
> executable bit isn't set -- perhaps because it's located in the cgi-bin
> directory. I suggest you open http://.../cgi-bin/gitweb/gitweb.css and try
> to get it to display the CSS file in your browser; this is a problem with
> your web server, not with gitweb.
I moved gitweb outside of cgi-bin and now it works OK. Thanks!
>
> (By the way, git-favicon.png and gitweb_config.perl shouldn't have their
> executable bits set either, since they're not CGI scripts.)
>
Sure.
Thanks,
Erez
> -- Lea
>
^ permalink raw reply
* [PATCH v2 2/2] Extend parse-options test suite
From: Stephan Beyer @ 2008-06-22 15:04 UTC (permalink / raw)
To: Michele Ballabio
Cc: git, Pierre Habouzit, Junio C Hamano, Johannes Schindelin,
Stephan Beyer
In-Reply-To: <1214147066-10979-1-git-send-email-s-beyer@gmx.net>
This patch serves two purposes:
1. test-parse-option.c should be a more complete
example for the parse-options API, and
2. there have been no tests for OPT_CALLBACK,
OPT_DATE, OPT_BIT, OPT_SET_INT and OPT_SET_PTR
before.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
t/t0040-parse-options.sh | 116 +++++++++++++++++++++++++++++++++++++++++++---
test-parse-options.c | 39 ++++++++++++++--
2 files changed, 144 insertions(+), 11 deletions(-)
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 9965cfa..6309aed 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -11,23 +11,35 @@ cat > expect.err << EOF
usage: test-parse-options <options>
-b, --boolean get a boolean
+ -4, --or4 bitwise-or boolean with ...0100
+
-i, --integer <n> get a integer
-j <n> get a integer, too
+ --set23 set integer to 23
+ -t <time> get timestamp of <time>
+ -L, --length <str> get length of <str>
-string options
+String options
-s, --string <string>
get a string
--string2 <str> get another string
--st <st> get another string (pervert ordering)
-o <str> get another string
+ --default-string set string to default
-magic arguments
+Magic arguments
--quux means --quux
+Standard options
+ --abbrev[=<n>] use <n> digits to display SHA-1s
+ -v, --verbose be verbose
+ -n, --dry-run dry run
+ -q, --quiet be quiet
+
EOF
test_expect_success 'test help' '
- ! test-parse-options -h > output 2> output.err &&
+ test_must_fail test-parse-options -h > output 2> output.err &&
test ! -s output &&
test_cmp expect.err output.err
'
@@ -36,21 +48,31 @@ cat > expect << EOF
boolean: 2
integer: 1729
string: 123
+abbrev: 7
+verbose: 2
+quiet: no
+dry run: yes
EOF
test_expect_success 'short options' '
- test-parse-options -s123 -b -i 1729 -b > output 2> output.err &&
+ test-parse-options -s123 -b -i 1729 -b -vv -n > output 2> output.err &&
test_cmp expect output &&
test ! -s output.err
'
+
cat > expect << EOF
boolean: 2
integer: 1729
string: 321
+abbrev: 10
+verbose: 2
+quiet: no
+dry run: no
EOF
test_expect_success 'long options' '
test-parse-options --boolean --integer 1729 --boolean --string2=321 \
+ --verbose --verbose --no-dry-run --abbrev=10 \
> output 2> output.err &&
test ! -s output.err &&
test_cmp expect output
@@ -60,6 +82,10 @@ cat > expect << EOF
boolean: 1
integer: 13
string: 123
+abbrev: 7
+verbose: 0
+quiet: no
+dry run: no
arg 00: a1
arg 01: b1
arg 02: --boolean
@@ -76,6 +102,10 @@ cat > expect << EOF
boolean: 0
integer: 2
string: (not set)
+abbrev: 7
+verbose: 0
+quiet: no
+dry run: no
EOF
test_expect_success 'unambiguously abbreviated option' '
@@ -99,6 +129,10 @@ cat > expect << EOF
boolean: 0
integer: 0
string: 123
+abbrev: 7
+verbose: 0
+quiet: no
+dry run: no
EOF
test_expect_success 'non ambiguous option (after two options it abbreviates)' '
@@ -107,20 +141,24 @@ test_expect_success 'non ambiguous option (after two options it abbreviates)' '
test_cmp expect output
'
-cat > expect.err << EOF
+cat > typo.err << EOF
error: did you mean \`--boolean\` (with two dashes ?)
EOF
test_expect_success 'detect possible typos' '
- ! test-parse-options -boolean > output 2> output.err &&
+ test_must_fail test-parse-options -boolean > output 2> output.err &&
test ! -s output &&
- test_cmp expect.err output.err
+ test_cmp typo.err output.err
'
cat > expect <<EOF
boolean: 0
integer: 0
string: (not set)
+abbrev: 7
+verbose: 0
+quiet: no
+dry run: no
arg 00: --quux
EOF
@@ -130,4 +168,68 @@ test_expect_success 'keep some options as arguments' '
test_cmp expect output
'
+cat > expect <<EOF
+boolean: 0
+integer: 1
+string: default
+abbrev: 7
+verbose: 0
+quiet: yes
+dry run: no
+arg 00: foo
+EOF
+
+test_expect_success 'OPT_DATE() and OPT_SET_PTR() work' '
+ test-parse-options -t "1970-01-01 00:00:01 +0000" --default-string \
+ foo -q > output 2> output.err &&
+ test ! -s output.err &&
+ test_cmp expect output
+'
+
+cat > expect <<EOF
+Callback: "four", 0
+boolean: 5
+integer: 4
+string: (not set)
+abbrev: 7
+verbose: 0
+quiet: no
+dry run: no
+EOF
+
+test_expect_success 'OPT_CALLBACK() and OPT_BIT() work' '
+ test-parse-options --length=four -b -4 > output 2> output.err &&
+ test ! -s output.err &&
+ test_cmp expect output
+'
+
+cat > expect <<EOF
+Callback: "not set", 1
+EOF
+
+test_expect_success 'OPT_CALLBACK() and callback errors work' '
+ test_must_fail test-parse-options --no-length > output 2> output.err &&
+ test_cmp expect output &&
+ test_cmp expect.err output.err
+'
+
+cat > expect <<EOF
+boolean: 1
+integer: 23
+string: (not set)
+abbrev: 7
+verbose: 0
+quiet: no
+dry run: no
+EOF
+
+test_expect_success 'OPT_BIT() and OPT_SET_INT() work' '
+ test-parse-options --set23 -bbbbb --no-or4 > output 2> output.err &&
+ test ! -s output.err &&
+ test_cmp expect output
+'
+
+# --or4
+# --no-or4
+
test_done
diff --git a/test-parse-options.c b/test-parse-options.c
index 73360d7..2a79e72 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -2,9 +2,22 @@
#include "parse-options.h"
static int boolean = 0;
-static int integer = 0;
+static unsigned long integer = 0;
+static int abbrev = 7;
+static int verbose = 0, dry_run = 0, quiet = 0;
static char *string = NULL;
+int length_callback(const struct option *opt, const char *arg, int unset)
+{
+ printf("Callback: \"%s\", %d\n",
+ (arg ? arg : "not set"), unset);
+ if (unset)
+ return 1; /* do not support unset */
+
+ *(unsigned long *)opt->value = strlen(arg);
+ return 0;
+}
+
int main(int argc, const char **argv)
{
const char *usage[] = {
@@ -13,15 +26,29 @@ int main(int argc, const char **argv)
};
struct option options[] = {
OPT_BOOLEAN('b', "boolean", &boolean, "get a boolean"),
+ OPT_BIT('4', "or4", &boolean,
+ "bitwise-or boolean with ...0100", 4),
+ OPT_GROUP(""),
OPT_INTEGER('i', "integer", &integer, "get a integer"),
OPT_INTEGER('j', NULL, &integer, "get a integer, too"),
- OPT_GROUP("string options"),
+ OPT_SET_INT(0, "set23", &integer, "set integer to 23", 23),
+ OPT_DATE('t', NULL, &integer, "get timestamp of <time>"),
+ OPT_CALLBACK('L', "length", &integer, "str",
+ "get length of <str>", length_callback),
+ OPT_GROUP("String options"),
OPT_STRING('s', "string", &string, "string", "get a string"),
OPT_STRING(0, "string2", &string, "str", "get another string"),
OPT_STRING(0, "st", &string, "st", "get another string (pervert ordering)"),
OPT_STRING('o', NULL, &string, "str", "get another string"),
- OPT_GROUP("magic arguments"),
+ OPT_SET_PTR(0, "default-string", &string,
+ "set string to default", (unsigned long)"default"),
+ OPT_GROUP("Magic arguments"),
OPT_ARGUMENT("quux", "means --quux"),
+ OPT_GROUP("Standard options"),
+ OPT__ABBREV(&abbrev),
+ OPT__VERBOSE(&verbose),
+ OPT__DRY_RUN(&dry_run),
+ OPT__QUIET(&quiet),
OPT_END(),
};
int i;
@@ -29,8 +56,12 @@ int main(int argc, const char **argv)
argc = parse_options(argc, argv, options, usage, 0);
printf("boolean: %d\n", boolean);
- printf("integer: %d\n", integer);
+ printf("integer: %lu\n", integer);
printf("string: %s\n", string ? string : "(not set)");
+ printf("abbrev: %d\n", abbrev);
+ printf("verbose: %d\n", verbose);
+ printf("quiet: %s\n", quiet ? "yes" : "no");
+ printf("dry run: %s\n", dry_run ? "yes" : "no");
for (i = 0; i < argc; i++)
printf("arg %02d: %s\n", i, argv[i]);
--
1.5.6.310.g344d
^ permalink raw reply related
* [PATCH v2 1/2] api-parse-options.txt: Introduce documentation for parse options API
From: Stephan Beyer @ 2008-06-22 15:04 UTC (permalink / raw)
To: Michele Ballabio
Cc: git, Pierre Habouzit, Junio C Hamano, Johannes Schindelin,
Stephan Beyer
In-Reply-To: <200806221639.04811.barra_cuda@katamail.com>
Add some documentation of basics, macros and callback
implementation of the parse-options API.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Ha, great ;)
So here are my patches, now based on your one.
Regards,
Stephan
Documentation/technical/api-parse-options.txt | 204 ++++++++++++++++++++++++-
1 files changed, 202 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index b7cda94..60a433b 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -1,6 +1,206 @@
parse-options API
=================
-Talk about <parse-options.h>
+The parse-options API is used to parse and massage options in git
+and to provide a usage help with consistent look.
-(Pierre)
+Basics
+------
+
+The argument vector `argv[]` may usually contain mandatory or optional
+'non-option arguments', e.g. a filename or a branch, and 'options'.
+Options are optional arguments that start with a dash and
+that allow to change the behavior of a command.
+
+* There are basically three types of options:
+ 'boolean' options,
+ options with (mandatory) 'arguments' and
+ options with 'optional arguments'
+ (i.e. a boolean option that can be adjusted).
+
+* There are basically two forms of options:
+ 'Short options' consist of one dash (`-`) and one alphanumeric
+ character.
+ 'Long options' begin with two dashes (`\--`) and some
+ alphanumeric characters.
+
+* Options are case-sensitive.
+ Please define 'lower-case long options' only.
+
+The parse-options API allows:
+
+* 'sticked' and 'separate form' of options with arguments.
+ `-oArg` is sticked, `-o Arg` is separate form.
+ `\--option=Arg` is sticked, `\--option Arg` is separate form.
+
+* Long options may be 'abbreviated', as long as the abbreviation
+ is unambiguous.
+
+* Short options may be bundled, e.g. `-a -b` can be specified as `-ab`.
+
+* Boolean long options can be 'negated' (or 'unset') by prepending
+ `no-`, e.g. `\--no-abbrev` instead of `\--abbrev`.
+
+* Options and non-option arguments can clearly be separated using the `\--`
+ option, e.g. `-a -b \--option \-- \--this-is-a-file` indicates that
+ `\--this-is-a-file` must not be processed as an option.
+
+Steps to parse options
+----------------------
+
+. `#include "parse-options.h"`
+
+. define a NULL-terminated
+ `static const char * const builtin_foo_usage[]` array
+ containing alternative usage strings
+
+. define `builtin_foo_options` array as described below
+ in section 'Data Structure'.
+
+. in `cmd_foo(int argc, const char **argv, const char *prefix)`
+ call
+
+ argc = parse_options(argc, argv, builtin_foo_options, builtin_foo_usage, flags);
++
+`parse_options()` will filter out the processed options of `argv[]` and leave the
+non-option arguments in `argv[]`.
+`argc` is updated appropriately because of the assignment.
++
+Flags are the bitwise-or of:
+
+`PARSE_OPT_KEEP_DASHDASH`::
+ Keep the `\--` that usually separates options from
+ non-option arguments.
+
+`PARSE_OPT_STOP_AT_NON_OPTION`::
+ Usually the whole argument vector is massaged and reordered.
+ Using this flag, processing is stopped at the first non-option
+ argument.
+
+Data Structure
+--------------
+
+The main data structure is an array of the `option` struct,
+say `static struct option builtin_add_options[]`.
+There are some macros to easily define options:
+
+`OPT__ABBREV(&int_var)`::
+ Add `\--abbrev[=<n>]`.
+
+`OPT__DRY_RUN(&int_var)`::
+ Add `-n, \--dry-run`.
+
+`OPT__QUIET(&int_var)`::
+ Add `-q, \--quiet`.
+
+`OPT__VERBOSE(&int_var)`::
+ Add `-v, \--verbose`.
+
+`OPT_GROUP(description)`::
+ Start an option group. `description` is a short string that
+ describes the group or an empty string.
+ Start the description with an upper-case letter.
+
+`OPT_BOOLEAN(short, long, &int_var, description)`::
+ Introduce a boolean option.
+ `int_var` is incremented on each use.
+
+`OPT_BIT(short, long, &int_var, description, mask)`::
+ Introduce a boolean option.
+ If used, `int_var` is bitwise-ored with `mask`.
+
+`OPT_SET_INT(short, long, &int_var, description, integer)`::
+ Introduce a boolean option.
+ If used, set `int_var` to `integer`.
+
+`OPT_SET_PTR(short, long, &ptr_var, description, ptr)`::
+ Introduce a boolean option.
+ If used, set `ptr_var` to `ptr`.
+
+`OPT_STRING(short, long, &str_var, arg_str, description)`::
+ Introduce an option with string argument.
+ The string argument is put into `str_var`.
+
+`OPT_INTEGER(short, long, &int_var, description)`::
+ Introduce an option with integer argument.
+ The integer is put into `int_var`.
+
+`OPT_DATE(short, long, &int_var, description)`::
+ Introduce an option with date argument, see `approxidate()`.
+ The timestamp is put into `int_var`.
+
+`OPT_CALLBACK(short, long, &var, arg_str, description, func_ptr)`::
+ Introduce an option with argument.
+ The argument will be fed into the function given by `func_ptr`
+ and the result will be put into `var`.
+ See 'Option Callbacks' below for a more elaborate description.
+
+`OPT_ARGUMENT(long, description)`::
+ Introduce a long-option argument that will be kept in `argv[]`.
+
+
+The last element of the array must be `OPT_END()`.
+
+If not stated otherwise, interpret the arguments as follows:
+
+* `short` is a character for the short option
+ (e.g. `\'e\'` for `-e`, use `0` to omit),
+
+* `long` is a string for the long option
+ (e.g. `"example"` for `\--example`, use `NULL` to omit),
+
+* `int_var` is an integer variable,
+
+* `str_var` is a string variable (`char *`),
+
+* `arg_str` is the string that is shown as argument
+ (e.g. `"branch"` will result in `<branch>`).
+ If set to `NULL`, three dots (`...`) will be displayed.
+
+* `description` is a short string to describe the effect of the option.
+ It shall begin with a lower-case letter and a full stop (`.`) shall be
+ omitted at the end.
+
+Option Callbacks
+----------------
+
+The function must be defined in this form:
+
+ int func(const struct option *opt, const char *arg, int unset)
+
+The callback mechanism is as follows:
+
+* Inside `funct`, the only interesting member of the structure
+ given by `opt` is the void pointer `opt->value`.
+ `\*opt->value` will be the value that is saved into `var`, if you
+ use `OPT_CALLBACK()`.
+ For example, do `*(unsigned long *)opt->value = 42;` to get 42
+ into an `unsigned long` variable.
+
+* Return value `0` indicates success and non-zero return
+ value will invoke `usage_with_options()` and, thus, die.
+
+* If the user negates the option, `arg` is `NULL` and `unset` is 1.
+
+Sophisticated option parsing
+----------------------------
+
+If you need, for example, option callbacks with optional arguments
+or without arguments at all, or if you need other special cases,
+that are not handled by the macros above, you need to specify the
+members of the `option` structure manually.
+
+This is not covered in this document, but well documented
+in `parse-options.h` itself.
+
+Examples
+--------
+
+See `test-parse-options.c` and
+`builtin-add.c`,
+`builtin-clone.c`,
+`builtin-commit.c`,
+`builtin-fetch.c`,
+`builtin-fsck.c`,
+`builtin-rm.c`
+for real-world examples.
--
1.5.6.310.g344d
^ permalink raw reply related
* Re: [StGIT PATCH 1/4] Allow e-mails to be sent with the Unix sendmail tool
From: Karl Hasselström @ 2008-06-22 15:10 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080619214201.27794.18891.stgit@localhost.localdomain>
On 2008-06-19 22:42:01 +0100, Catalin Marinas wrote:
> If the stgit.smtpserver configuration option does not have a
> host:port format, it is assumed to be an external tool. For example,
> to use sendmail just set this variable to "/usr/sbin/sendmail -t -i"
> (see the examples/gitconfig file).
Some comments below, but it looks good.
> +def __send_message_sendmail(sendmail, msg):
> + """Send the message using the sendmail command.
> + """
> + cmd = sendmail.split()
> + Run(*cmd).raw_input(msg).discard_output()
You could've written this without the "cmd" variable, but I understand
why you didn't. The * operator (or whatever it is) isn't pretty. I
sort of regret not making Run take a list argument instead, frankly.
> class GitConfig:
> __defaults={
> 'stgit.autoresolved': 'no',
> - 'stgit.smtpserver': 'localhost:25',
> + 'stgit.smtpserver': '/usr/sbin/sendmail -t -i',
Hmm. I think it's actually more common to have a misconfigured (or
insufficiently configured) sendmail program than a misconfigured mail
daemon listening to port 25, so I'd argue that the default shouldn't
be changed. But it's not that important.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGIT PATCH 2/4] Implement a new patch identification scheme and id command
From: Karl Hasselström @ 2008-06-22 15:27 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080619214210.27794.76950.stgit@localhost.localdomain>
On 2008-06-19 22:42:10 +0100, Catalin Marinas wrote:
> The new scheme allows '[<branch>:]<patch>' and '[<branch>:]{base}'
> (the latter showing the base of a stack). The former format allows
> symbols like ^ and ^{...}.
Hmm. Why only the former? Supporting it for the latter should be easy.
(Though it would take some extra work, I guess.)
Other than that, it looks good to me.
> +def git_commit(name, repository, branch = None):
> + """Return the a Commit object if 'name' is a patch name or Git commit.
> + The patch names allowed are in the form '<branch>:<patch>' and can be
> + followed by standard symbols used by git-rev-parse. If <patch> is '{base}',
Long line.
> + # The stack base
> + if patch == '{base}':
> + return repository.get_stack(branch).base
Should be a simple matter of
if patch.startswith('{base}'):
foo = repository.get_stack(branch).base + drop_prefix(patch, '{base}')
return repository.rev_parse(foo)
or something.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGIT PATCH 3/4] Convert git_id() to the new id format
From: Karl Hasselström @ 2008-06-22 15:48 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080619214222.27794.74083.stgit@localhost.localdomain>
On 2008-06-19 22:42:22 +0100, Catalin Marinas wrote:
> The patch rewrites git_id() to use the new id format and coverts the
> commands using this function. The git_id() will be removed once all
> the commands are converted to the new infrastructure where
> git_commit() will be used instead.
Looks good. And the code volume reduction is significant.
> if not rev:
> + # backwards compatibility
> return None
Could you expand this comment a bit? It's not enough of a clue for me.
:-/
> -def git_commit(name, repository, branch = None):
> +def git_commit(name, repository, branch_name = None):
Very nice parameter rename here, now that we have Branch objects (and
use a crappy language with no type system).
> -rev = '([patch][//[bottom | top]]) | <tree-ish> | base'
> -
> -If neither bottom nor top are given but a '//' is present, the command
> -shows the specified patch (defaulting to the current one)."""
> +rev = '([branch:]patch) | <tree-ish> | base'
You can remove the parentheses now; they were only needed because they
used to enclose a complicated expression. Besides, shouldn't it be
[branch:]{base} instead of base? So something like
rev = [<branch>:]<patch> | [<branch>:]{base} | <tree-ish>
> help = 'show the files modified by a patch (or the current patch)'
> -usage = """%prog [options] [<patch>]
> +usage = """%prog [options] [[<branch>:]<patch>]
Unrelated to this patch: I realized last week that it's silly for stg
files to not accept a patch range.
> if len(args) == 0:
> - patch = ''
> + patch = 'HEAD'
Ah, so this is the backwards compatibility thing -- we used to pass
the empty string when we meant HEAD.
> - (refpatchname, refbranchname, refpatchid) = parse_rev(patchname)
> - if refpatchname and not refpatchid and \
> - (not refpatchid or refpatchid == 'top'):
> - # FIXME: should also support picking //top.old
> + refbranchname, refpatchname = parse_rev(patchname)
> + if refpatchname:
The corresponding TODO comment now would be that pick should be able
to pick patches from the past, from the stack log.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGIT PATCH 4/4] Remove the applied/unapplied commands
From: Karl Hasselström @ 2008-06-22 16:13 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080619214233.27794.98487.stgit@localhost.localdomain>
On 2008-06-19 22:42:33 +0100, Catalin Marinas wrote:
> This patch moves the applied/unapplied functionality to the 'series'
> command via the corresponding options.
Nice.
> make_option('-a', '--all',
> help = 'show all patches, including the hidden ones',
> action = 'store_true'),
> + make_option('--applied',
> + help = 'show the applied patches only',
> + action = 'store_true'),
> + make_option('--unapplied',
> + help = 'show the unapplied patches only',
> + action = 'store_true'),
> make_option('--hidden',
> help = 'show the hidden patches only',
> action = 'store_true'),
Maybe some logic to prohibit the use of more than one of these at
once? The current logic is kind of arbitrary.
Also, we should perhaps invent good single-letter abbreviations for
these presumably rather common flags. -a is taken; -A and -U perhaps?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.6
From: Steffen Prohaska @ 2008-06-22 16:54 UTC (permalink / raw)
To: Git Mailing List, msysGit; +Cc: Junio C Hamano
In-Reply-To: <7vmylixr6h.fsf@gitster.siamese.dyndns.org>
On Jun 19, 2008, at 1:24 AM, Junio C Hamano wrote:
> The latest feature release GIT 1.5.6 is available at the usual
> places:
The msysgit Windows installer is available at
http://code.google.com/p/msysgit/downloads
Steffen
^ permalink raw reply
* Re: [PATCH 1/2] parse_options: Add flag to prevent errors for further processing
From: Pierre Habouzit @ 2008-06-22 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Shawn Bohrer, git
In-Reply-To: <7vwskn1g2p.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]
On Wed, Jun 18, 2008 at 05:13:02AM +0000, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I think the only right way to accomplish this is to convert the revision
> > and diff parameters into a parseopt-understandable format.
>
> Not necessarily. You could structure individual option parsers like how
> diff option parsers are done. You iterate over argv[], feed diff option
> parser the current index into argv[] and ask if it is an option diff
> understands, have diff eat the option (and possibly its parameter) to
> advance the index, or allow diff option to say "I do not understand this",
> and then handle it yourself or hand it to other parsers.
If you do that, you need to relocate pars option structures, and we
decided some time ago that it wasn't a good idea. Note that "recursing"
is not really trivial, because with flags aggregation and stuff like
that, things that look like an option can also be a value in the context
of an other option parser.
That's why we settled for the other way Dscho pointed. But for that, I
need to work on it more than what I really have time to nowadays, and
moreover, it needs some things (the setup_revisions split and the log
traversal bits change) to be merged.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [jgit PATCH] Paper bag fix quoting for SSH transport commands
From: Robin Rosenberg @ 2008-06-22 17:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Marek Zawirski
In-Reply-To: <20080622013640.GA18629@spearce.org>
söndagen den 22 juni 2008 03.36.40 skrev Shawn O. Pearce:
> Not all Git-over-SSH servers run a Bourne shell on the remote side
> to evaluate the command we are sending. Some servers run git-shell,
> which will fail to execute git-upload-pack if we feed it a quoted
> string for the name git-upload-pack.
>
> Testing concludes that git-shell requires the command name to never
> be quoted, and the argument name to always be single quoted. As
> this is a long-standing behavior in the wild jgit needs to conform,
> as git-shell and all git-shell work-a-likes such as gitosis may be
> following the same convention.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>
> If there are no arguments I'll push this into the public tree.
> It seems right on the surface, and is necessary to use jgit against
> repo.or.cz, and probably many other sites like it.
Seems ok and works here. Error handling still has a paperbagish feel. See
follow up patches.
Maybe we should have a patch for git too so it will actually work with spaces in file names. What do people on Windows do? (those that actually get an SSH server up and running and sleep well overe it on that platform).
As for pushing and signing. One way is for you (Shawn) and me is to sign-off and push each other's patches. I pushed this one.
-- robin
^ permalink raw reply
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