Just to clarify: The normal way to check for changes in a repository is
There are many factors that come into play with git performance, and
although it is inherently fast compared to a remote repository system like
Subversion, it involves a lot of clever techniques on the file-system, using
a lot of indexing and compression.
This means, when it slows down, it's kind of hard to trace what's wrong
without being a bit of a git/filesystem/operating-system wizard.
For example, it could be due to heavy fragmentation of the disk sectors
where your slow repository is stored. It could also be that your filesystem
is slowing down the procedure. Which filesystem are you running? What are
your hard-drive specs? Operating system? Git version?
It does sound odd that the larger repository is fast compared to the small
one. Can you say something about the nature of the two repos? Is there a lot
of binary (images) data in one of them? How many files are in there? How big
are the .git folders compared to the rest?
Sometimes it helps asking git to repackage its index/repository (garbage
If you want additional ways of asking for the diff between two points in
time in the repository, the general syntax is this:
git diff <commit1> <commit2>
where the commits can be either SHA's, or tags.
If you leave out the first one like this:
git diff <commit>
.. the diff is between HEAD and <commit>
You can also use *git log* for seeing the commit log between two points in
time, as well as git show, for looking at single commits.
For example, here's the log with diff (-p) for the last three commits:
git log -p HEAD~3
And here, showing only the changed files:
git logv -p HEAD~3 --name-status
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at