threads / discuss / 7906

git-rev-parse(1) questions

Subject: git-rev-parse(1) questions

## tl;dr

4 messages between Apr 30, 2007 and Apr 30, 2007.

replies: 3people: 4as markdown or json

Jari Aalto· Apr 30, 2007, 18:24 UTC · lore
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
Linus Torvalds· Apr 30, 2007, 18:49 UTC · re: Jari Aalto · lore

Re: git-rev-parse(1) questions

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
Junio C Hamano· Apr 30, 2007, 20:20 UTC · re: Linus Torvalds · lore

Re: git-rev-parse(1) questions

Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 18 quoted lines
> 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 ;-).

Johannes Schindelin· Apr 30, 2007, 18:51 UTC · re: Jari Aalto · lore

Re: git-rev-parse(1) questions

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

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

← back to recent threads