Now, "git show" obviously does exactly what you probably wanted, but for
future reference, the "git log" family of commands also take a "number of
commits" limiter.
So you can also do things like
git log --cc -1 X
and it will actually do something very similar to "git show". It's not
_quite_ identical, but it's close - at least for the special case of a
single commit.
"git show" actually uses a magic "no_walk" internal flag which means that
you can give it _several_ revisions, and it will take them as a raw "list"
of revisions rather than take them as a command to "walk" the revision
space and then just show one of them (like the "git log --cc -1" example
would do).
So with "git show", you can do
git show X Y Z
and it will show those exact three commits. That's _different_ from
git log --cc -3 X Y Z
which will show the three "most recent" commits when you start walking the
revision DAG. (The above "git log" command really doesn't make much sense,
since the output will depend on commit date - it has well-specified
behaviour, but it's really a pretty random thing to do: it might, for
example, show the three commits X, X^ and Z, and not Y at all).
Anyway, "git show" is a very useful thing. It's actually one of the
commands I use most. If I ever want to see what happened in a single
commit (eg somebody sends me a bug-report and says "commit XYZ introduced
a regression"), that's what I would use.
Looking at my history, the commands I tend to use most are:
git log
git diff
git pull <some-remote-repo>
gitk ORIG_HEAD..
git log -p some/directory/or/file
git grep -w <some-identifier> [possibly-some-subdirectory]
git show <some-rev>
and while I think that "git pull" and "gitk ORIG_HEAD.." thing tends to be
something special to being a top-level maintainer (although maybe I'm
wrong - you'd probably do the same just because you're following a remote
tree under active development), all the rest are commands that everybody
should know so intimately that they don't even need to think about them.
"git grep" in particular seems to be something that a lot of people
haven't necessarily even realized is there. Yet it's actually extremely
powerful and efficient both for the "current tree" and for "old
revisions".
It's interesting: I used to do a lot of "plain grep" usage, but with git,
most of my greps by far are all of the form "git grep". I've gotten so
used to it that I find myself wanting to do "git grep" even on non-git
stuff, and if I look at somebody elses tar-ball I often end up doing
git init-db
git add .
just to be able to do "git grep" on it. I've totally stopped doing the
"find . -name '*.[ch]' | xargs grep -w" sequence that I _used_ to do a lot
of.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
