The output of the "git log" command can be made more or less verbose
by means of the --pretty option. For example, with "git log
--pretty=short" the commit identifier will be omitted and only the
The output of the "git log" command can be made more or less verbose
by means of the --pretty option. For example, with "git log
--pretty=short" the commit identifier will be omitted and only the
--pretty=fuller", (the name 'fuller' is in contrast to the default
--pretty=full), the committer name and dates will be printed in
addition to the author name and dates.
--pretty=fuller", (the name 'fuller' is in contrast to the default
--pretty=full), the committer name and dates will be printed in
addition to the author name and dates.
complete commit identifier, (perhaps in bug-tracking systems to
indicate a specific commit that fixes a bug, for example). But often,
in more casual settings, it's more convenient to use abbreviated
complete commit identifier, (perhaps in bug-tracking systems to
indicate a specific commit that fixes a bug, for example). But often,
in more casual settings, it's more convenient to use abbreviated
-commit identifiers. Git accept any unique prefix of a commit
-identifier, (and for reasonably-sized project the first 8 or 10
+commit identifiers. Git accepts any unique prefix of a commit
+identifier, (and for reasonably-sized projects the first 8 or 10
characters are almost always unique).
And unlike the permanent commit identifiers, git also provides
characters are almost always unique).
And unlike the permanent commit identifiers, git also provides
Or perhaps you'd like to see the actual patch content of each change,
which you can get with -p. That commit with the word typo in its name
Or perhaps you'd like to see the actual patch content of each change,
which you can get with -p. That commit with the word typo in its name
it as master~3, HEAD~3, or any prefix of its commit identifier, (such
as 13ed136b):
it as master~3, HEAD~3, or any prefix of its commit identifier, (such
as 13ed136b):
#### 2.7.3 Writing a good commit message
A good commit message will generally have a single line that
#### 2.7.3 Writing a good commit message
A good commit message will generally have a single line that
with supporting detail. Since many tools only print the first line of
a commit message by default, it’s important that the first line stands
alone.
with supporting detail. Since many tools only print the first line of
a commit message by default, it’s important that the first line stands
alone.
the progress-tracking spew were reduced to a single line. Something
like "Computing (100%) Transferring (100%)" or whatever.
the progress-tracking spew were reduced to a single line. Something
like "Computing (100%) Transferring (100%)" or whatever.
files were modified, (which is very useful for getting a quick feel
for what happened). If you would like more details on what changes
came in, git provides a range that is perfect for examining. Let's
files were modified, (which is very useful for getting a quick feel
for what happened). If you would like more details on what changes
came in, git provides a range that is perfect for examining. Let's
Sometimes you may not know if you want to pull in the changes from the
remote repository or not. It's useful to be able to examine them
before accepting them into our branch. The "git pull" command shown in
Sometimes you may not know if you want to pull in the changes from the
remote repository or not. It's useful to be able to examine them
before accepting them into our branch. The "git pull" command shown in
"git fetch" and "git merge". We can use these commands separately to
examine the change before accepting it.
"git fetch" and "git merge". We can use these commands separately to
examine the change before accepting it.
These remote-tracking branches make it very easy to collaborate with
people as they are working on experimental features not yet ready for
upstream inclusion. For example, if fred's latest code is still
These remote-tracking branches make it very easy to collaborate with
people as they are working on experimental features not yet ready for
upstream inclusion. For example, if fred's latest code is still
project's primary repository. But he may still want my help with
it. So he can push it to a branch in his own repository for which I've
got a remote. Then on my next "git fetch fred" I might notice a new
project's primary repository. But he may still want my help with
it. So he can push it to a branch in his own repository for which I've
got a remote. Then on my next "git fetch fred" I might notice a new