Re: [PATCH 2/2] Document rev^! and rev^@ as revision specifiers

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 2/2] Document rev^! and rev^@ as revision specifiers

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:54:13

Max Horn [off-list ref] writes:
+'<rev>{caret}@', e.g. 'HEAD{caret}@'::
+  A suffix '{caret}' followed by an at sign
+  means all parents of '<rev>'.
+  This is somewhat different from the other specifiers in this
+  section in that it may refer to multiple commits at once.
+  See also the next section on SPECIFYING RANGES.
Looks good.

+'<rev>{caret}!', e.g. 'HEAD{caret}!'::
+  A suffix '{caret}' followed by an exclamation mark
+  means commit '<rev>' but forces all of its parents to be excluded. For
+  commands that deal with a single revision, this is the same as '<rev>".
Is this sentence correct?  "git commit -C 'HEAD^!'" might be a
command that expects a single revision, but I do not think it is the
same as "git commit -C HEAD".
+  Hence it is primarily used with commands expecting commit ranges.
That is correct.

Re: [PATCH 2/2] Document rev^! and rev^@ as revision specifiers

From: Max Horn <hidden>
Date: 2016-06-15 22:54:13


Am 06.07.2012 um 09:21 schrieb Junio C Hamano [off-list ref]:
Max Horn [off-list ref] writes:
quoted
+'<rev>{caret}@', e.g. 'HEAD{caret}@'::
+  A suffix '{caret}' followed by an at sign
+  means all parents of '<rev>'.
+  This is somewhat different from the other specifiers in this
+  section in that it may refer to multiple commits at once.
+  See also the next section on SPECIFYING RANGES.
Looks good.

quoted
+'<rev>{caret}!', e.g. 'HEAD{caret}!'::
+  A suffix '{caret}' followed by an exclamation mark
+  means commit '<rev>' but forces all of its parents to be excluded. For
+  commands that deal with a single revision, this is the same as '<rev>".
Is this sentence correct?  "git commit -C 'HEAD^!'" might be a
command that expects a single revision, but I do not think it is the
same as "git commit -C HEAD".
Ignoring the exact words I used for the moment, what I meant is that these two commands should be functionally equivalent. Aren't they? If not, I obviously misunderstand something, and would like to learn more, and add a better explanation.

If they are equivalent in the sense that the end results are indistinguishable,, and you just dislike the (indeed inaccurate) choice of words, how about replacing "is the same as" by "is [functionally] equivalent".


Thank you very much for your reviews,
Max

quoted
+  Hence it is primarily used with commands expecting commit ranges.
That is correct.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help