Re: git-rev-parse(1) questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]