* [PATCH 2/2] archive: limit ourselves during remote requests
From: Jeff King @ 2011-11-15 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, git
In-Reply-To: <20111115214159.GA20457@sigill.intra.peff.net>
Originally, the call-chain of an upload-archive invocation
was like:
cmd_archive (on local machine)
run_remote_archiver (local)
cmd_upload_archive (on remote machine)
run_upload_archive (remote)
write_archive (remote)
And write_archive knew that it could be remotely invoked,
and didn't trust the arguments given to it when doing
anything security-critical.
Since c09cd77 (upload-archive: use start_command instead of
fork, 2011-10-24), we exec a git-archive subprocess, and the
call-chain is now:
cmd_archive (local)
run_remote_archiver (local)
cmd_upload_archive (remote)
cmd_archive (in a sub-process)
write_archive
The arbitrary arguments we get from the client are passed
through cmd_archive via the command-line of git-archive.
Unlike write_archive, cmd_archive was never taught not to
trust the remote arguments. Among the many horrible things a
malicious client could do were:
- accessing another repository as the user running on the
server, using "--remote"
- execute arbitrary code as the user running on the server
using "--remote --exec"
- overwrite arbitrary files using "--output"
This patch causes cmd_archive to respect the remote-request
flag immediately and chain to write_archive, ignoring any
other options.
Signed-off-by: Jeff King <peff@peff.net>
---
This is the minimal required to fix it.
I mentioned already the alternative of allowing through only known-good
arguments in upload-pack's prepare_argv. I don't like that because it
means we have to know about every option that write_archive is OK with.
I think a more sensible solution would be a new command, "git
upload-archive--remote", which is just a very stripped-down version of
git-archive (i.e., it _only_ calls write_archive). Or it could even be
spelled "git upload-archive --remote-request". But the point is that
git-archive never needed to worry about security before. We
shouldn't be polluting it with security code; we should be bypassing it
going to write_archive directly.
For the tests, checking each failure mode is perhaps overkill, but I
want to be double sure that this doesn't ever regress.
builtin/archive.c | 9 +++++++++
t/t5000-tar-tree.sh | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/builtin/archive.c b/builtin/archive.c
index fce20a1..ee2fb54 100644
--- a/builtin/archive.c
+++ b/builtin/archive.c
@@ -104,6 +104,15 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, local_opts, NULL,
PARSE_OPT_KEEP_ALL);
+ /*
+ * We want to ignore all other parsed options in the remote case, as
+ * they come from an arbitrary client. Therefore we shouldn't do things
+ * like write files based on --output, or make new --remote
+ * connections.
+ */
+ if (is_remote)
+ return write_archive(argc, argv, prefix, 0, NULL, 1);
+
if (output)
create_output_file(output);
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 723b54e..5679c79 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -317,6 +317,45 @@ test_expect_success 'malicious clients cannot un-remote themselves' '
test_must_fail git upload-archive . <evil-request >remote.tar.foo
'
+# Again, we have to hand-craft our malicious request. Since parsing
+# the output to determine that we did indeed get subrepo would be hard,
+# instead we use an easier test: try to get a branch only in the subrepo,
+# which must fail if our hack doesn't work.
+test_expect_success 'malicious clients cannot access repos via --remote' '
+ git init subrepo &&
+ (cd subrepo &&
+ test_commit subrepo &&
+ git branch only-in-subrepo
+ ) &&
+ {
+ echo "0021argument --remote=../subrepo"
+ echo "001dargument only-in-subrepo" &&
+ printf "0000"
+ } >evil-request &&
+ test_must_fail git upload-archive . <evil-request >evil-output
+'
+
+test_expect_success 'malicious clients cannot exec code via --remote' '
+ {
+ echo "0021argument --remote=../subrepo"
+ echo "0026argument --exec=echo foo >hax0red"
+ echo "0012argument HEAD" &&
+ printf "0000"
+ } >evil-request &&
+ test_might_fail git upload-archive . <evil-request >evil-output &&
+ test_path_is_missing .git/hax0red
+'
+
+test_expect_success 'malicious clients cannot trigger --output on server' '
+ {
+ echo "001dargument --output=p0wn3d"
+ echo "0012argument HEAD" &&
+ printf "0000"
+ } >evil-request &&
+ git upload-archive . <evil-request >remote.tar &&
+ test_path_is_missing .git/p0wn3d
+'
+
if $GZIP --version >/dev/null 2>&1; then
test_set_prereq GZIP
else
--
1.7.7.3.8.g38efa
^ permalink raw reply related
* Re: [PATCH 3/7] sequencer: handle single-commit pick as special case
From: Junio C Hamano @ 2011-11-15 21:58 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Jonathan Nieder
In-Reply-To: <CALkWK0krTY+szqPrE9wxwfK76VBbFXh_Xaz8EyWZayLa_SFQTw@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Hi Junio,
>
> Junio C Hamano writes:
>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>> [...]
>> [...]
>> I do not see an inconsistency here, let alone any "glaring" one.
>
> Yeah, my commit message is totally misleading and unclear. Yes, all
> the operations make sense to you and me; for a new user who doesn't
> understand how Git works, it's completely inconsistent at a very
> superficial level, no? The sequence of operations he has to execute
> depends on:
> 1. If he literally specified a single commit or a commit range on the
> command-line.
But we are already in agreement on this point, I think. Didn't I say:
It is a different story if the sequence were like this:
$ git cherry-pick foo
... conflict happens
$ edit problematicfile
$ git add problematicfile
$ git cherry-pick --continue
... This should notice CHERRY_PICK_HEAD and record it.
... After that, there is nothing remaining to be done.
In other words, the user said "I want to replay this commit", the command
couldn't finish it by itself and asked the user to help resolving the
conflict, the user resolved and told the command to continue. The command
should continue recording the result.
And if "continue" does not work in this sequence, that is a bug worth
fixing.
in the message you are responding to?
> 2. In the case of multi-commit picking, there's an additional layer of
> decision making: did the conflict occur in the last commit in the
> range?
Again, it would be the same thing. If the implementation forces that
decision, that would be a bug, no?
My understanding is that multi-commit form of cherry-pick and revert
intended to allow two forms of "user done helping and telling the command
to continue" at any stage, be it the first, in the middle, or the last
operation in a series:
- User resolves, adds and commits, and then tells the command to
continue. The command notices that the user has committed, and goes on
to the next task; or
- User resolves, adds, and then tells the command to continue. The
command notices that the user has not committed, makes a commit and
goes on to the next task.
I think "rebase -i" works the same way and both are valid ways to tell the
command to continue.
Now, multi-commit form of cherry-pick/revert _may_ be buggy (I do not use
that form often myself to know if this is the case, though) and may only
allow one or the other depending on which commit in the series the user is
asked to help, but if that is the case it is a bug in the implementation
of the multi-commit form done back in v1.7.2 timeframe.
^ permalink raw reply
* Re: [PATCH 0/2] upload-archive security issues
From: Erik Faye-Lund @ 2011-11-15 22:01 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20111115214159.GA20457@sigill.intra.peff.net>
On Tue, Nov 15, 2011 at 10:42 PM, Jeff King <peff@peff.net> wrote:
> Looking at Erik's c09cd77e again, there are some serious security
> problems, in that we are too lenient with what gets passed to
> git-archive, which is not hardened to accept random client arguments.
> That lets a client do all sorts of nasty things like running arbitrary
> code.
>
> These patches fix it by making cmd_archive handle the remote-request
> flag better. An alternative would be to pass only known-good options
> through upload-archive. That might be more future-proof, but also
> involves upload-archive knowing about the innards of write_archive and
> its options. See also the comments in patch 2/2 for another alternative
> fix.
>
> [1/2]: archive: don't allow negation of --remote-request
> [2/2]: archive: limit ourselves during remote requests
Yikes! Perhaps the whole deal of rewriting the code to take explicit
file descriptors (and/or dup-bonanza) would have been the better
choice after all?
For the record: I would be fine with c09cd77e simply being reverted
for this release, and having a better version applied in the near
future. Windows support for upload-archive is not worth the risk of
slipping in a remote code execution bug...
>
> And yes, I feel like a moron for not noticing these problems during my
> initial review.
Not only did you fail to spot them, you actually wrote that part of the code ;)
http://article.gmane.org/gmane.comp.version-control.git/178098
(I don't mean to shift blame over to you, I'm the one who should have
spent more time thinking about this as this was "my" series)
^ permalink raw reply
* Re: [PATCH 0/2] upload-archive security issues
From: Jeff King @ 2011-11-15 22:23 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Junio C Hamano, git
In-Reply-To: <CABPQNSZ71==pQvH9nTQ3rD6c1RJiLmkA+k_9KS=T45cQb+PTLA@mail.gmail.com>
On Tue, Nov 15, 2011 at 11:01:09PM +0100, Erik Faye-Lund wrote:
> Yikes! Perhaps the whole deal of rewriting the code to take explicit
> file descriptors (and/or dup-bonanza) would have been the better
> choice after all?
It's certainly simpler. This way is not that hard to fix; we just need
to be more careful about the code path getting from upload-archive into
write_archive.
> For the record: I would be fine with c09cd77e simply being reverted
> for this release, and having a better version applied in the near
> future. Windows support for upload-archive is not worth the risk of
> slipping in a remote code execution bug...
I'd be OK with that, too.
> Not only did you fail to spot them, you actually wrote that part of the code ;)
>
> http://article.gmane.org/gmane.comp.version-control.git/178098
>
> (I don't mean to shift blame over to you, I'm the one who should have
> spent more time thinking about this as this was "my" series)
Heh. I did say "something like this" in that message, which is usually a
sure sign I haven't actually thought too hard about the code I'm about
to write. I'll be content to share the blame equally with you. :)
-Peff
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Junio C Hamano @ 2011-11-15 23:10 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Dmitry Smirnov, git
In-Reply-To: <CAJo=hJvdstr39suGMwxNoT+_cKThxsEYHi96eqja7HuHyPmhWA@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> On Tue, Nov 15, 2011 at 05:52, Dmitry Smirnov <divis1969@gmail.com> wrote:
>
>> If I use the http URL (http://git.kernel.org/pub/scm/git/git.git) I
>> can clone with no problems.
>
> This may be a problem with the git.kernel.org HTTP server. It is
> probably not a problem with Git itself.
Not likely to be an issue with git.kernel.org either. I am puzzled.
$ git ls-remote https://git.kernel.org/pub/scm/git/git.git |
grep -e HEAD -e master
bc1bbe0c19a6ff39522b4fa3259f34150e308e1f HEAD
bc1bbe0c19a6ff39522b4fa3259f34150e308e1f refs/heads/master
$ rungit v1.7.5.4 ls-remote https://git.kernel.org/pub/scm/git/git.git |
grep -e HEAD -e master
bc1bbe0c19a6ff39522b4fa3259f34150e308e1f HEAD
bc1bbe0c19a6ff39522b4fa3259f34150e308e1f refs/heads/master
The only thing that immediately comes to mind is the rare smart-http
breakage in 1.7.5 but that was plugged in 1.7.5.1, so...
^ permalink raw reply
* Re: [PATCH 3/4] ll-merge: initialize default_opts const
From: Junio C Hamano @ 2011-11-15 23:17 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Thomas Rast
In-Reply-To: <1321376379-31750-4-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> ll-merge.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/ll-merge.c b/ll-merge.c
> index da59738..205aed3 100644
> --- a/ll-merge.c
> +++ b/ll-merge.c
> @@ -351,7 +351,7 @@ int ll_merge(mmbuffer_t *result_buf,
> const struct ll_merge_options *opts)
> {
> static struct git_attr_check check[2];
> - static const struct ll_merge_options default_opts;
> + static const struct ll_merge_options default_opts = {0, 0, 0, 0};
Doesn't "static" tell us that it will be in BSS, initialized to all zero
by definition?
^ permalink raw reply
* Re: odd name-rev behavior?
From: Junio C Hamano @ 2011-11-15 23:20 UTC (permalink / raw)
To: Tim Walberg; +Cc: git
In-Reply-To: <20111115211514.GE27706@comcast.net>
Tim Walberg <twalberg@comcast.net> writes:
> Never noticed this before - is this expected? It doesn't seem to
> match documentation, in any case...
>
> Basically, 'git name-rev --all' lists a lot of lines that are
> marked as "undefined", and most, if not all, of the objects
> represented are trees, not commits... I wouldn't have expected
> name-rev to follow the link from a commit to a tree and try to
> process that result...
I wouldn't either, but this does not look like a recent breakage. v1.6.0
seems to show the same broken behaviour.
^ permalink raw reply
* Re: odd name-rev behavior?
From: Junio C Hamano @ 2011-11-15 23:23 UTC (permalink / raw)
To: git; +Cc: Tim Walberg
In-Reply-To: <7vpqgtt1kb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Tim Walberg <twalberg@comcast.net> writes:
>
>> Never noticed this before - is this expected? It doesn't seem to
>> match documentation, in any case...
>>
>> Basically, 'git name-rev --all' lists a lot of lines that are
>> marked as "undefined", and most, if not all, of the objects
>> represented are trees, not commits... I wouldn't have expected
>> name-rev to follow the link from a commit to a tree and try to
>> process that result...
>
> I wouldn't either, but this does not look like a recent breakage. v1.6.0
> seems to show the same broken behaviour.
And this one-liner should be sufficient (untested).
builtin/name-rev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 7864056..1b37458 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -291,7 +291,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
max = get_max_object_index();
for (i = 0; i < max; i++) {
struct object *obj = get_indexed_object(i);
- if (!obj)
+ if (!obj || obj->type != OBJ_COMMIT)
continue;
show_name(obj, NULL,
always, allow_undefined, data.name_only);
^ permalink raw reply related
* Re: hook for rebase --continue
From: Neal Kreitzinger @ 2011-11-15 23:28 UTC (permalink / raw)
To: Matt Graham; +Cc: git
In-Reply-To: <CALts4TQ545L1d1J0EiUjd7x=WBJpjCCv6UsXZOoGQAC29RqC5g@mail.gmail.com>
On 11/7/2011 1:42 PM, Matt Graham wrote:
> Hi, I did some testing and it appears that during a rebase, if I
> resolve a conflict and call git rebase --continue, the pre-commit
> hook doesn't run. This means that if I don't resolve the conflict
> correctly, our check for invalid syntax doesn't get run and creates
> the risk that someone could push code with invalid syntax, not
> realizing that the check didn't run.
>
> Does anyone else share my expectation that the pre-commit hook
> should run during a rebase? Or at least for the first commit
> following a rebase conflict?
>
> If not, is there another hook that is triggered by a rebase that I
> should be using instead?
>
I just noticed there is a post-rewrite hook in the manpage
http://schacon.github.com/git/githooks.html. Maybe this does what you want.
v/r,
neal
^ permalink raw reply
* Re: [PATCH 0/2] upload-archive security issues
From: Junio C Hamano @ 2011-11-15 23:40 UTC (permalink / raw)
To: Jeff King; +Cc: Erik Faye-Lund, git
In-Reply-To: <20111115222320.GA28646@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> For the record: I would be fine with c09cd77e simply being reverted
>> for this release, and having a better version applied in the near
>> future. Windows support for upload-archive is not worth the risk of
>> slipping in a remote code execution bug...
>
> I'd be OK with that, too.
Ok, that is easier ;-)
^ permalink raw reply
* Re: [PATCH 2/2] archive: limit ourselves during remote requests
From: Junio C Hamano @ 2011-11-16 0:03 UTC (permalink / raw)
To: Jeff King; +Cc: Erik Faye-Lund, git
In-Reply-To: <20111115214840.GB20624@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... just a very stripped-down version of
> git-archive (i.e., it _only_ calls write_archive). Or it could even be
> spelled "git upload-archive --remote-request". But the point is that
> git-archive never needed to worry about security before. We
> shouldn't be polluting it with security code; we should be bypassing it
> going to write_archive directly.
Quite sensible, and a good approach to reroll the series, I would think.
^ permalink raw reply
* Re: [PATCH] revert: prettify fatal messages
From: Junio C Hamano @ 2011-11-16 1:05 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Jonathan Nieder
In-Reply-To: <1321349492-5653-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Candidate for 'maint'?
Too minor to matter when 'master' is already at -rc2.
Thanks.
^ permalink raw reply
* Re: odd name-rev behavior?
From: Tim Walberg @ 2011-11-16 1:48 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <7vlirht1fw.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
That does indeed seem to work on first try. Not sure it was
a particularly critical issue - just unexpected. For what I
was using it for it was simple to work around. But thanks
for the quick fix!
tw
On 11/15/2011 15:23 -0800, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> > Tim Walberg <twalberg@comcast.net> writes:
>> >
>> >> Never noticed this before - is this expected? It doesn't seem to
>> >> match documentation, in any case...
>> >>
>> >> Basically, 'git name-rev --all' lists a lot of lines that are
>> >> marked as "undefined", and most, if not all, of the objects
>> >> represented are trees, not commits... I wouldn't have expected
>> >> name-rev to follow the link from a commit to a tree and try to
>> >> process that result...
>> >
>> > I wouldn't either, but this does not look like a recent breakage. v1.6.0
>> > seems to show the same broken behaviour.
>>
>> And this one-liner should be sufficient (untested).
>>
>> builtin/name-rev.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/builtin/name-rev.c b/builtin/name-rev.c
>> index 7864056..1b37458 100644
>> --- a/builtin/name-rev.c
>> +++ b/builtin/name-rev.c
>> @@ -291,7 +291,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
>> max = get_max_object_index();
>> for (i = 0; i < max; i++) {
>> struct object *obj = get_indexed_object(i);
>> - if (!obj)
>> + if (!obj || obj->type != OBJ_COMMIT)
>> continue;
>> show_name(obj, NULL,
>> always, allow_undefined, data.name_only);
End of included message
--
+----------------------+
| Tim Walberg |
| 830 Carriage Dr. |
| Algonquin, IL 60102 |
| twalberg@comcast.net |
+----------------------+
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git, Parrot, Perl6, Rakudo for G4 MAC
From: Sitaram Chamarty @ 2011-11-16 4:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Hilco Wijbenga, Greg, git
In-Reply-To: <m3fwhpmf1f.fsf@localhost.localdomain>
2011/11/15 Jakub Narebski <jnareb@gmail.com>:
> Git requires Perl version 5.8 at least, so you should not have any
> problems here.
One day someone [1] reminded me that git does not require perl. Some
features, like git add -p, require it but git can be built without
perl.
[1] on irc, while discussing my stated requirements for gitolite
^ permalink raw reply
* Re: input director not compatible with git right-click
From: Sitaram Chamarty @ 2011-11-16 4:52 UTC (permalink / raw)
To: Carlos Martín Nieto, Sitaram Chamarty, Eric, git
In-Reply-To: <20111115173843.GB5453@centaur.lab.cmartin.tk>
On Tue, Nov 15, 2011 at 11:08 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Tue, Nov 15, 2011 at 09:39:25PM +0530, Sitaram Chamarty wrote:
>> On Mon, Nov 14, 2011 at 8:10 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
>> > On Sun, Nov 13, 2011 at 04:34:26PM +0000, Eric wrote:
>> >> Hi,
>> >>
>> >> New in Git use, I use it do dev on window some administrative script. I use as
>> >> well Input director to share keyboard and mouse on multiple computer.
>> >
>> > Do you mean you're using it on the Windows OS?
>> >
>> >>
>> >> when I right-clicked on an item, it works when input director is disabled. If
>> >
>> > Right-click on what? git doesn't have a graphical interface. If you're
>> > using a graphical front-end to git, you should send them a bug report.
>>
>> git comes with 3 perfectly cromulent graphical programs, and one of
>> them is indispensable.
>
> I guess we have diferent ideas of where "git" ends and other stuff
> starts. gitk, git-gui and what is the last one?
'git gui blame'
^ permalink raw reply
* Re: odd name-rev behavior?
From: Junio C Hamano @ 2011-11-16 5:41 UTC (permalink / raw)
To: Tim Walberg; +Cc: git
In-Reply-To: <20111116014842.GF27706@comcast.net>
Tim Walberg <twalberg@comcast.net> writes:
> That does indeed seem to work on first try. Not sure it was
> a particularly critical issue - just unexpected.
I didn't think it is particularly critical, either, and that is why I said
it has been like this for eons at least since v1.6.0.
And it turns out that this was pretty much from day one of name-rev at
bd321bc (Add git-name-rev, 2005-10-26).
^ permalink raw reply
* Re: [PATCH] git-show-ref: fix escaping in asciidoc source
From: Michael Haggerty @ 2011-11-16 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk471urfy.fsf@alter.siamese.dyndns.org>
On 11/15/2011 08:16 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> Did this one fall through the cracks? I don't see it in your tree.
>
> Yeah, I was wondering if we can have a concise description in what context
> any "^" must be spelled as {caret} and what other context "^" can be
> spelled literally, and possibly which versions of AsciiDoc toolchain have
> this issue [*1*]. Without a clear guideline, people may unknowingly use
> literal "^" to new paragraphs, or perhaps worse yet, spell {caret} that
> end up being shown literally.
>
> Since I didn't find a clear pattern other than that "^" can and should be
> literally given in a literal paragraph (i.e. an indented paragraph or
> inside a listing/literal block that shows program examples), I was meaning
> to ask you if you knew the rules better than I did, and I stopped there,
> forgetting to follow through.
I didn't know anything about asciidoc, and just tried to fix it using a
bit of cargo-cult programming.
Now I just did about an hour of research about asciidoc (but I still
don't feel very enlightened). It seems that asciidoc was interpreting
the caret, paired with one earlier in the paragraph, as markup asking
for the enclosed text to be superscripted [1]. Apparently, single
carets in a paragraph are not treated as markup, which would explain
some apparent inconsistency about when carets need to be quoted. But it
would seem prudent to escape all carets that don't appear in literal blocks.
Constructs like "{caret}" are "simple attribute references". In this
particular case, the attribute that it is referencing is not built into
asciidoc but rather defined in the file Documentation/asciidoc.conf.
Empirically it seems that curly braces need to be escaped if they can be
interpreted to be part of an attribute reference, but not otherwise.
For example, curly braces with nothing inside of them like "{}" don't
necessarily need to be quoted, but it doesn't hurt if they are quoted to
"\{\}".
The backslash escape rules are a bit mysterious to me. Backslash can be
used to escape some special characters. For example, they can be used
to escape leading special quoting characters to avoid the special
effect, like "\_not italic_" [3]. They can also be used to suppress
attribute references, like "\{caret}" [4]. But it doesn't appear
possible to use a backslash to escape another backslash; for example
"\\{carat}" is rendered as "\{carat}". In such cases, the backslash can
be spelled "{backslash}" (which is also defined in asciidoc.conf).
How to quote a monstrosity like the regexp in git-show-ref.txt? We want
it to render as
^(?:<anything>\s)?<refname>(?:\^{})?$
, probably in monospaced font and surrounded by double quotes. asciidoc
supports a bewildering variety of quoting mechanisms [5]. Empirically,
"`^(?:<anything>\s)?<refname>(?:\^{})?$`"
doesn't work (the backticks don't suppress superscripting).
A pedestrian option is
"`{caret}(?:<anything>\s)?<refname>(?:{backslash}{caret}\{\})?$`"
or
"`{caret}(?:<anything>\s)?<refname>(?:{backslash}{caret}{})?$`"
Or the whole blob can be quoted en masse using $$:
"`$$^(?:<anything>\s)?<refname>(?:\^{})?$$$`"
I don't know whether it treats the last dollar signs as "$$ $" or "$
$$", but either way the result looks OK.
I can't believe I spent my whole morning on this :-(
Michael
[1]
http://www.methods.co.nz/asciidoc/userguide.html#_superscripts_and_subscripts
[2]
http://www.methods.co.nz/asciidoc/userguide.html#_simple_attributes_references
[3] http://www.methods.co.nz/asciidoc/userguide.html#X51
[4] http://www.methods.co.nz/asciidoc/userguide.html#_attribute_references
[5] http://www.methods.co.nz/asciidoc/userguide.html#X77
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 3/4] ll-merge: initialize default_opts const
From: Ramkumar Ramachandra @ 2011-11-16 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Thomas Rast
In-Reply-To: <7vty65t1qp.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> [...]
>> diff --git a/ll-merge.c b/ll-merge.c
>> index da59738..205aed3 100644
>> --- a/ll-merge.c
>> +++ b/ll-merge.c
>> @@ -351,7 +351,7 @@ int ll_merge(mmbuffer_t *result_buf,
>> const struct ll_merge_options *opts)
>> {
>> static struct git_attr_check check[2];
>> - static const struct ll_merge_options default_opts;
>> + static const struct ll_merge_options default_opts = {0, 0, 0, 0};
>
> Doesn't "static" tell us that it will be in BSS, initialized to all zero
> by definition?
I'm uncertain about whether the C89 standard says this explicitly- icc
is more pedantic than most mainstream compilers. Feel free to drop
this part if you don't think it adds value.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 3/5] sequencer: sequencer state is useless without todo
From: Ramkumar Ramachandra @ 2011-11-16 6:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Git List
In-Reply-To: <7v7h31wduv.fsf@alter.siamese.dyndns.org>
Hi,
Jonathan Nieder wrote:
> Just use a sane idiom. Which means: as few git_path() values in
> flight at a time as possible.
Makes sense, thanks.
Junio C Hamano wrote:
> Or perhaps http://thread.gmane.org/gmane.comp.version-control.git/184963/focus=185436
I noticed that sha1_to_hex() also operates like this. The
resolve_ref() function is really important, but using the same
technique for these tiny functions is probably an overkill; something
in `Documentation/technical` perhaps?
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH] revert: prettify fatal messages
From: Ramkumar Ramachandra @ 2011-11-16 6:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jonathan Nieder, Matthieu Moy
In-Reply-To: <7vvcqkswpu.fsf@alter.siamese.dyndns.org>
Hi,
Matthieu Moy wrote:
> (I just misread the subject line at first, and understood that this was> a revert of an earlier commit, while this is actually a commit touching> the "revert" part of Git)
Reminds me of an earlier note Jonathan made about the git-revert
commit message format. To avoid confusion, reverts should always look
like the following:
Revert [commit message]
This reverts commit [unabbreviated sha1 hex].
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> Candidate for 'maint'?
>
> Too minor to matter when 'master' is already at -rc2.
Ah, I haven't been paying much attention to these release cycles. I
suppose we can put this patch in `master` after the release? I wince
everytime I see these ugly fatal messages: it happens shockingly often
while testing :)
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 3/7] sequencer: handle single-commit pick as special case
From: Ramkumar Ramachandra @ 2011-11-16 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jonathan Nieder
In-Reply-To: <7v62ilujya.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> [...]
> But we are already in agreement on this point, I think. Didn't I say:
Yes, yes. I was just thinking out loud so it'll help me write a new
commit message. Sorry for the noise.
>> 2. In the case of multi-commit picking, there's an additional layer of
>> decision making: did the conflict occur in the last commit in the
>> range?
>
> Again, it would be the same thing. If the implementation forces that
> decision, that would be a bug, no?
>
> My understanding is that multi-commit form of cherry-pick and revert
> intended to allow two forms of "user done helping and telling the command
> to continue" at any stage, be it the first, in the middle, or the last
> operation in a series:
>
> - User resolves, adds and commits, and then tells the command to
> continue. The command notices that the user has committed, and goes on
> to the next task; or
>
> - User resolves, adds, and then tells the command to continue. The
> command notices that the user has not committed, makes a commit and
> goes on to the next task.
Yep, this is exactly how it'll work after the series :D
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH] revert: prettify fatal messages
From: Jonathan Nieder @ 2011-11-16 6:42 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List, Matthieu Moy
In-Reply-To: <CALkWK0m+us0rCx61+SwSsKuO7qK5mbCs0MpoAzB4ja=wBA+Xjw@mail.gmail.com>
Ramkumar Ramachandra wrote:
> To avoid confusion, reverts should always look
> like the following:
>
> Revert [commit message]
>
> This reverts commit [unabbreviated sha1 hex].
Don't forget the description of why it is being reverted. :)
Actually, I think Matthieu's confusion makes a lot of sense. I don't
think it matters very much, but it can sometimes be clearer to say
"cherry-pick/revert: remove spurious period in error message".
Another benefit to moving the juicy part to sequencer.c, I guess.
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Dmitry Smirnov @ 2011-11-16 7:04 UTC (permalink / raw)
To: git; +Cc: Shawn Pearce
In-Reply-To: <CAJo=hJvdstr39suGMwxNoT+_cKThxsEYHi96eqja7HuHyPmhWA@mail.gmail.com>
2011/11/15 Shawn Pearce <spearce@spearce.org>:
> I would suggest starting over by downloading repo per [1] and using
> that script to start the process.
Cloning of the repo.git repository produces the same error
warning: remote HEAD refers to nonexistent ref, unable to checkout.
That is why I tried to use another repository...
^ permalink raw reply
* Re: Git, Parrot, Perl6, Rakudo for G4 MAC
From: greggallen @ 2011-11-16 7:07 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Jakub Narebski, Hilco Wijbenga, git
In-Reply-To: <CAMK1S_jcThEB=_w=miGBncmTEy8jz6_T-QHv7g-C5s3Hi+X6Lg@mail.gmail.com>
Thank you very much for all your help. After a tiny bit of
consideration, I've decided to sell my G4, for whatever I can get on
the local Craigslist, and install Linux, or FreeBSD on this &^%^$$&*!!
Wintel machine.
Copying my several dozen useful Perl and shell scripts, will be much
easier to accomplish than "GITting" the other stuff to install on a
PPC MAC. I love programming, but INSTALLING software is boring!
Thanks again,
Greg Allen
GreggAllen@gmail.com
On 11/15/11, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> 2011/11/15 Jakub Narebski <jnareb@gmail.com>:
>
>> Git requires Perl version 5.8 at least, so you should not have any
>> problems here.
>
> One day someone [1] reminded me that git does not require perl. Some
> features, like git add -p, require it but git can be built without
> perl.
>
> [1] on irc, while discussing my stated requirements for gitolite
>
--
**********************************************
Descargo de responsabilidad:
(Nulo donde esté prohibido, su kilometraje puede variar, consulte con
su médico, todos los derechos reservados, cualquier retransmisión o
retransmisión de las descripciones y las cuentas de este juego está
prohibida sin el consentimiento expreso por escrito de la Major League
Baseball).
Disclaimer:
(Void where prohibited, your mileage may vary, check with your doctor,
all rights reserved, any rebroadcast or retransmission of the
descriptions and accounts of this game is prohibited without the
expressed written consent of Major League Baseball.)
Haftungsausschluss:
(Void, wo die Leistung kann variieren, fragen Sie Ihren Arzt verboten,
alle Rechte vorbehalten, jegliche Weiterverbreitung oder
Weiterverbreitung von Beschreibungen und Berichte über dieses Spiel
ist ohne ausdrückliche schriftliche Zustimmung der Major League
Baseball verboten.)
Rejettent la Déclaration:
(Nul si interdit, votre kilométrage peut varier, vérifiez auprès de
votre médecin, tous droits réservés, toute rediffusion ou
retransmission des descriptions et des comptes de ce jeu est interdite
sans l'accord écrit de la Major League Baseball).
Negano la Dichiarazione:
(valido dove proibito, le prestazioni possono variare, verificare con
il medico, tutti i diritti riservati, ogni ritrasmissione o
ritrasmissione delle descrizioni e dei conti di questo gioco è vietato
senza il consenso scritto della Major League Baseball.)
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Dmitry Smirnov @ 2011-11-16 7:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7v1ut9uglb.fsf@alter.siamese.dyndns.org>
2011/11/16 Junio C Hamano <gitster@pobox.com>:
> $ git ls-remote https://git.kernel.org/pub/scm/git/git.git |
> grep -e HEAD -e master
in my case this command produce no output.
What if problem is caused by curl or TLS lib (libcurl-gnutls?) which
is used by my git? Is there any to log something from git-remote-https
?
Dmitry
^ 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