threads / discuss / 2028

Confused as to the correct syntax

Subject: Confused as to the correct syntax

## tl;dr

6 messages between Oct 5, 2005 and Oct 6, 2005.

replies: 5people: 3as markdown or json

Alan Chandler· Oct 5, 2005, 22:50 UTC · lore

The man page for git-rev-parse talks about the way to specify commits back from a named commit object. The following text in this man page tries to explain it, but it has confused me more

"A suffix ~<n> to a revision parameter means the commit object that is the <n>th generation grand-parent of the named commit object, following only the first parent. I.e. rev~3 is equivalent to rev^ which is equivalent to rev11^1."

Why is rev~3 equivalent to rev^,  surely it is equivalent to rev^^^
Why is rev~3 equivalent to rev11^1, should that not be rev^1^1^1

I don't understand the syntax here - so was looking it up in the man page. Is there an error in the page or have I misunderstood something.

-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
Junio C Hamano· Oct 5, 2005, 23:16 UTC · re: Alan Chandler · lore

Re: Confused as to the correct syntax

Alan Chandler <alan@chandlerfamily.org.uk> writes:
Show 8 quoted lines
> "A  suffix  ~<n>  to  a  revision parameter means the commit object that is 
> the <n>th generation grand-parent of the named commit object, following only 
> the first parent. I.e. rev~3 is equivalent to rev^ which is equivalent to 
> rev11^1."
>
> Why is rev~3 equivalent to rev^,  surely it is equivalent to rev^^^
>
> Why is rev~3 equivalent to rev11^1, should that not be rev^1^1^1
Sorry, for not knowing how to do that properly in Asciidoc ;-).
The source to the man page and HTML page reads like this:
* A suffix '~<n>' to a revision parameter means the commit
  object that is the <n>th generation grand-parent of the named
  commit object, following only the first parent.  I.e. rev~3 is
  equivalent to rev^^^ which is equivalent to rev^1^1^1.
Alan Chandler· Oct 5, 2005, 23:33 UTC · re: Junio C Hamano · lore

Re: Confused as to the correct syntax

On Thursday 06 Oct 2005 00:16, Junio C Hamano wrote:
Show 18 quoted lines
> Alan Chandler <alan@chandlerfamily.org.uk> writes:
> > "A  suffix  ~<n>  to  a  revision parameter means the commit object that
> > is the <n>th generation grand-parent of the named commit object,
> > following only the first parent. I.e. rev~3 is equivalent to rev^ which
> > is equivalent to rev11^1."
> >
> > Why is rev~3 equivalent to rev^,  surely it is equivalent to rev^^^
> >
> > Why is rev~3 equivalent to rev11^1, should that not be rev^1^1^1
>
> Sorry, for not knowing how to do that properly in Asciidoc ;-).
>
> The source to the man page and HTML page reads like this:
>
> * A suffix '~<n>' to a revision parameter means the commit
>   object that is the <n>th generation grand-parent of the named
>   commit object, following only the first parent.  I.e. rev~3 is
>   equivalent to rev^^^ which is equivalent to rev^1^1^1.
No the HTML page is screwed up too.
-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
Junio C Hamano· Oct 5, 2005, 23:54 UTC · re: Alan Chandler · lore

Re: Confused as to the correct syntax

Alan Chandler <alan@chandlerfamily.org.uk> writes:
Show 10 quoted lines
>> Sorry, for not knowing how to do that properly in Asciidoc ;-).
>>
>> The source to the man page and HTML page reads like this:
>>
>> * A suffix '~<n>' to a revision parameter means the commit
>>   object that is the <n>th generation grand-parent of the named
>>   commit object, following only the first parent.  I.e. rev~3 is
>>   equivalent to rev^^^ which is equivalent to rev^1^1^1.
>
> No the HTML page is screwed up too.

I know. The source reads like above, is what I said. Help from Asciidoc savvy people is very welcomed.

Jonas Fonseca· Oct 5, 2005, 23:42 UTC · re: Junio C Hamano · lore

[PATCH] Fix usage of carets in git-rev-parse(1)

... but using a {caret} attribute.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Junio C Hamano <junkio@cox.net> wrote Wed, Oct 05, 2005:
Show 12 quoted lines
> Alan Chandler <alan@chandlerfamily.org.uk> writes:
> 
> > "A  suffix  ~<n>  to  a  revision parameter means the commit object that is 
> > the <n>th generation grand-parent of the named commit object, following only 
> > the first parent. I.e. rev~3 is equivalent to rev^ which is equivalent to 
> > rev11^1."
> >
> > Why is rev~3 equivalent to rev^,  surely it is equivalent to rev^^^
> >
> > Why is rev~3 equivalent to rev11^1, should that not be rev^1^1^1
> 
> Sorry, for not knowing how to do that properly in Asciidoc ;-).
I think something like the following will do ...
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -7,6 +7,9 @@
 # Show GIT link as: <command>(<section>); if section is defined, else just show
 # the command.
 
+[attributes]
+caret=^
+
 ifdef::backend-docbook[]
 [gitlink-inlinemacro]
 {0%{target}}
@@ -19,3 +22,5 @@ ifdef::backend-xhtml11[]
 [gitlink-inlinemacro]
 <a href="{target}.html">{target}{0?({0})}</a>
 endif::backend-xhtml11[]
+
+
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -54,13 +54,13 @@ OPTIONS
 	`git-diff-\*`).
 
 --not::
-	When showing object names, prefix them with '^' and
-	strip '^' prefix from the object names that already have
+	When showing object names, prefix them with '{caret}' and
+	strip '{caret}' prefix from the object names that already have
 	one.
 
 --symbolic::
 	Usually the object names are output in SHA1 form (with
-	possible '^' prefix); this option makes them output in a
+	possible '{caret}' prefix); this option makes them output in a
 	form as close to the original input as possible.
 
 
@@ -93,22 +93,23 @@ what is called an 'extended SHA1' syntax
   happen to have both heads/master and tags/master, you can
   explicitly say 'heads/master' to tell GIT which one you mean.
 
-* A suffix '^' to a revision parameter means the first parent of
-  that commit object.  '^<n>' means the <n>th parent (i.e.
-  'rev^'
-  is equivalent to 'rev^1').  As a special rule,
-  'rev^0' means the commit itself and is used when 'rev' is the
+* A suffix '{caret}' to a revision parameter means the first parent of
+  that commit object.  '{caret}<n>' means the <n>th parent (i.e.
+  'rev{caret}'
+  is equivalent to 'rev{caret}1').  As a special rule,
+  'rev{caret}0' means the commit itself and is used when 'rev' is the
   object name of a tag object that refers to a commit object.
 
 * A suffix '~<n>' to a revision parameter means the commit
   object that is the <n>th generation grand-parent of the named
   commit object, following only the first parent.  I.e. rev~3 is
-  equivalent to rev^^^ which is equivalent to rev^1^1^1.
+  equivalent to rev{caret}{caret}{caret} which is equivalent to\
+  rev{caret}1{caret}1{caret}1.
 
-'git-rev-parse' also accepts a prefix '^' to revision parameter,
+'git-rev-parse' also accepts a prefix '{caret}' to revision parameter,
 which is passed to 'git-rev-list'.  Two revision parameters
 concatenated with '..' is a short-hand for writing a range
-between them.  I.e. 'r1..r2' is equivalent to saying '^r1 r2'
+between them.  I.e. 'r1..r2' is equivalent to saying '{caret}r1 r2'
 
 
 Author
-- 
Jonas Fonseca
Junio C Hamano· Oct 6, 2005, 00:06 UTC · re: Jonas Fonseca · lore

Re: [PATCH] Fix usage of carets in git-rev-parse(1)

Jonas Fonseca <fonseca@diku.dk> writes:
> ... but using a {caret} attribute.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>

Thanks. This seems to fix it. Applied and pushed out (but not in time for just released 0.99.8b).

← back to recent threads