Re: git-rev-parse(1) questions

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 30, 2007, 18:51 UTC
Message-ID: <Pine.LNX.4.64.0704302036520.29859@racer.site>
In-Reply-To: <mz0pwwi3.fsf@cante.net>

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