Could someone provide example commands where and how to use these:
* A suffix ^ followed by an empty brace pair (e.g. v0.99.8^{})
means the object could be a tag, and dereference the tag
recursively until a non-tag object is found.
* A colon, optionally followed by a stage number (0 to 3) and a
colon, followed by a path; this names a blob object in the index
at the given path. Missing stage number (and the colon that
follows it) names an stage 0 entry.
Jari
On Mon, 30 Apr 2007, Jari Aalto wrote:
Could someone provide example commands where and how to use these:
* A suffix ^ followed by an empty brace pair (e.g. v0.99.8^{})
means the object could be a tag, and dereference the tag
recursively until a non-tag object is found.
I don't think you'd normally use this much. It's more visible in things
like
git ls-remote <git-repo-name-here>
which will show tags and the objects they derefernce to, using the "^{}"
syntax. Normally you'd not use it in any day-to-day operation, although if
you want to, you could for example use
git show tag^{}
to show what the tag points to, without getting the tag part.
For an example, of this, in the git archive, do
git show junio-gpg-pub
vs
git show junio-gpg-pub^{}
and think about the difference in output.
But no, you'd not normally use this outside of scripts (and even inside
scripts, it's much more common to instead use "tag^0", which does
effectively the same *but* also requires the thing to be a commit.
* A colon, optionally followed by a stage number (0 to 3) and a
colon, followed by a path; this names a blob object in the index
at the given path. Missing stage number (and the colon that
follows it) names an stage 0 entry.
You'd never use this unless you're working with a unmerged tree entry, and
then you can use it for things like
git diff :1:my-path :2:their-path
if you want to look at the differences between the two blobs that are
unmerged, and come from different branches (":1:my-path" comes from the
branch you were merging things into,and the ":2:their-path" comes from the
branch you were merging from).
That can be useful in the extremely rare case where you had criss-crossing
renames, for example, and the recursive merge strategy couldn't resolve
them, and you realize that in order to merge it properly you'll need to
look at different pathnames that didn't pair up.
Normally, if the pathnames pair up, you'd normally just get a nice data
conflict and you'd likely just work with that.
I don't think anybody ever _normally_ uses the :n:path syntax. It's really
a very esoteric capability for when things go really really wrong, and you
want to see what the different stages contain.
Linus
Hi,
On Mon, 30 Apr 2007, Jari Aalto wrote:
Could someone provide example commands where and how to use these:
* A suffix ^ followed by an empty brace pair (e.g. v0.99.8^{})
means the object could be a tag, and dereference the tag
recursively until a non-tag object is found.
You can get at the _commit_ tagged with version 1.0.0 by doing "git
rev-parse v1.0.0^{}" (as opposed to the tag object).
* A colon, optionally followed by a stage number (0 to 3) and a
colon, followed by a path; this names a blob object in the index
at the given path. Missing stage number (and the colon that
follows it) names an stage 0 entry.
You can see that at best when you have a conflicted merge. For example, if
"git ls-files --unmerged" says that "README" is unmerged, "git show
:1:README" will show _your_ original version, while "git show :2:README"
will show the to-be-merged version.
Hth,
Dscho