Week 6"Referring to objects"
The Git spelling bee
It is now most definitely time we spoke about other ways to represent commit hashes.
More details can be found about this in the Git manual, but it is definitely worth spending a few minutes looking at the ways in which we can specify objects in the repository.
As you have seen in previous chapters, we have used branch names, commits hashes and tags to specify commits, but it is also possibly to use a variety of other methods to do so.
We are going to use the git rev-parse command again to return us an object hash from our description of an object.
These descriptions are ways to spell objects.
<SHA1> - This is most common way to specify an object.
The <SHA1> is the 40 character identifier that Git generates for each object.
As you have seen before, we do not have to specify the entire SHA1 hash, just the beginning portion that is unique.<refname> - We use this type of referencing a lot when checking out branches.
The <refname> is a symbolic name.
An example of this would be master, which actually refers to refs/heads/master, which you have seen in the .git directory.
HEAD is also a <refname>. In general, Git will search through a number of directories to find the <refname> that is being referred to;
.git/<name>refs/<name>refs/tags/<refname>refs/heads/<name>refs/remotes/<name>refs/remotes/<name>/HEAD
<refname>, Git would search in .git root directory first,
then into refs, followed by refs/tags, and finishing with refs/heads.<refname>@{date\} - Now we find a more interesting way of specifying references.
We can use something like master@{yesterday}, to show us the closeset commit to match that date time.
There are more complicated date specifications we can use as well, such as master@{"last week"}, or master@{"3 hours 2 minutes and 10 seconds ago"}.
We can even put in a specific date and time like so; master@{"2011-02-26 14:30:00"}<refname>@{<n>\} - This curious definition returns the commit that <refname> referred to <n> times in the past.
It uses the reflog, which has been discussed before, to discover what commit <refname> pointed to.
Be careful when using this reference. It does not mean the commit that <refname> pointed <n> commits ago in the tree.
If you have been doing resets and other things, these items show up in the reflog.<rev>^<n> - Is a way of asking Git to traverse an object for it's parents and so <rev> or <rev>^ 1 means the first parent of a commit object.
An example of this would be master^2.<rev>~<n> - Is a way of asking Git to traverse an object for it's <n>th grand-parent, following only first parents.
This will take a little understanding and it is advised that you read the man page online for more information about what this really means.<rev>^{/<text>\} - This definition actually initiates a search for the youngest commit where the commit message matches the regular expression after the slash.
master^{/bug\} is an example of the usage of this reference definition.<rev>:<path> - This allows us to obtain the object hash for the file specified at the <rev>.
We could then use the git show command to view that file.
As an example git show HEAD~ 3:readme.txt would show us the file readme.txt as it was three grandparents back from HEAD.
All of these are valid ways to refer to commits and in some cases objects and trees too.
Imagine a situation where you wanted to view a file called readme.txt that was three commits back from a tag of v44.
Using our new knowledge, we could use git show v44~ 3:readme.txt.
There are several other ways of referring to commits, but these are out of the scope of this chapter.
If you would like more information, refer to the man page for git rev-parse. |
|
