Re: git-rev-parse(1) questions

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 30, 2007, 18:49 UTC
Message-ID: <alpine.LFD.0.98.0704301138320.3419@woody.linux-foundation.org>
In-Reply-To: <mz0pwwi3.fsf@cante.net>

On Mon, 30 Apr 2007, Jari Aalto wrote:

Show 6 quoted lines

>
> 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