git-rev-parse(1) questions

git-rev-parse(1) questions

[Jari Aalto]

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

Re: git-rev-parse(1) questions

[Linus Torvalds]

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

Re: git-rev-parse(1) questions

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, 30 Apr 2007, Jari Aalto wrote:
>> ...
>>     * 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...

A small correction. :1:path comes from the common ancestor,
:2:mine comes from the branch you are on and merging into, and
:3:theirs is what the other branch you were merging from has.

People can see how rarely this is used interactively; even
original authors of git can get it wrong ;-).

Re: git-rev-parse(1) questions

[Johannes Schindelin]

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