* Confused as to the correct syntax @ 2005-10-05 22:50 Alan Chandler 2005-10-05 23:16 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Alan Chandler @ 2005-10-05 22:50 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Confused as to the correct syntax 2005-10-05 22:50 Confused as to the correct syntax Alan Chandler @ 2005-10-05 23:16 ` Junio C Hamano 2005-10-05 23:33 ` Alan Chandler 2005-10-05 23:42 ` [PATCH] Fix usage of carets in git-rev-parse(1) Jonas Fonseca 0 siblings, 2 replies; 6+ messages in thread From: Junio C Hamano @ 2005-10-05 23:16 UTC (permalink / raw) To: Alan Chandler; +Cc: git 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Confused as to the correct syntax 2005-10-05 23:16 ` Junio C Hamano @ 2005-10-05 23:33 ` Alan Chandler 2005-10-05 23:54 ` Junio C Hamano 2005-10-05 23:42 ` [PATCH] Fix usage of carets in git-rev-parse(1) Jonas Fonseca 1 sibling, 1 reply; 6+ messages in thread From: Alan Chandler @ 2005-10-05 23:33 UTC (permalink / raw) To: git On Thursday 06 Oct 2005 00:16, Junio C Hamano wrote: > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Confused as to the correct syntax 2005-10-05 23:33 ` Alan Chandler @ 2005-10-05 23:54 ` Junio C Hamano 0 siblings, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2005-10-05 23:54 UTC (permalink / raw) To: git Alan Chandler <alan@chandlerfamily.org.uk> writes: >> 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] Fix usage of carets in git-rev-parse(1) 2005-10-05 23:16 ` Junio C Hamano 2005-10-05 23:33 ` Alan Chandler @ 2005-10-05 23:42 ` Jonas Fonseca 2005-10-06 0:06 ` Junio C Hamano 1 sibling, 1 reply; 6+ messages in thread From: Jonas Fonseca @ 2005-10-05 23:42 UTC (permalink / raw) To: Junio C Hamano; +Cc: Alan Chandler, git ... but using a {caret} attribute. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> --- Junio C Hamano <junkio@cox.net> wrote Wed, Oct 05, 2005: > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Fix usage of carets in git-rev-parse(1) 2005-10-05 23:42 ` [PATCH] Fix usage of carets in git-rev-parse(1) Jonas Fonseca @ 2005-10-06 0:06 ` Junio C Hamano 0 siblings, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2005-10-06 0:06 UTC (permalink / raw) To: Jonas Fonseca; +Cc: Alan Chandler, git 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-10-06 0:06 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-10-05 22:50 Confused as to the correct syntax Alan Chandler 2005-10-05 23:16 ` Junio C Hamano 2005-10-05 23:33 ` Alan Chandler 2005-10-05 23:54 ` Junio C Hamano 2005-10-05 23:42 ` [PATCH] Fix usage of carets in git-rev-parse(1) Jonas Fonseca 2005-10-06 0:06 ` Junio C Hamano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).