commit a1a0e8b392b17caf50325498df54802fe3c03710
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 15:43:07 2005 -0700
-
+
Trim comments.
-
+
commit 72d4f10e4a27dbb09ace1503c20dbac1912ee451
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 13:15:58 2005 -0700
-
+
Get make to generate the final binary from a .o file.
-
+
commit 13ed136b983a9c439eddeea8a1c2076cffbb685f
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 13:15:43 2005 -0700
-
+
Introduce a typo into hello.c.
-
+
commit 0a633bf58b45fcf1a8299d3c82cd1fd26d3f48f2
Author: Bryan O'Sullivan <mpm@selenic.com>
Date: Fri Aug 26 01:21:28 2005 -0700
-
+
Create a makefile
-
+
commit db7117a9dd9a6e57e8632ea5848e1101eee0fbde
Author: Bryan O'Sullivan <mpm@selenic.com>
Date: Fri Aug 26 01:20:50 2005 -0700
-
+
Create a standard "hello, world" program
This command prints a record of output for each change to the project
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
-first line of each commit message will be show. And with "git log
+first line of each commit message will be shown. And with "git log
--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
-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
commit a1a0e8b392b17caf50325498df54802fe3c03710
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 15:43:07 2005 -0700
-
+
Trim comments.
-
+
commit 72d4f10e4a27dbb09ace1503c20dbac1912ee451
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 13:15:58 2005 -0700
-
+
Get make to generate the final binary from a .o file.
-
+
commit 13ed136b983a9c439eddeea8a1c2076cffbb685f
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 13:15:43 2005 -0700
-
+
Introduce a typo into hello.c.
#### 2.4.4 Other log filters
commit 72d4f10e4a27dbb09ace1503c20dbac1912ee451
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 13:15:58 2005 -0700
-
+
Get make to generate the final binary from a .o file.
-
+
commit 0a633bf58b45fcf1a8299d3c82cd1fd26d3f48f2
Author: Bryan O'Sullivan <mpm@selenic.com>
Date: Fri Aug 26 01:21:28 2005 -0700
-
+
Create a makefile
And "git log" can also filter based on the dates at which commits were
commit a1a0e8b392b17caf50325498df54802fe3c03710
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 15:43:07 2005 -0700
-
+
Trim comments.
-
+
hello.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
-
+
commit 72d4f10e4a27dbb09ace1503c20dbac1912ee451
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 13:15:58 2005 -0700
-
+
Get make to generate the final binary from a .o file.
-
+
Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
-
+
commit 13ed136b983a9c439eddeea8a1c2076cffbb685f
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 13:15:43 2005 -0700
-
+
Introduce a typo into hello.c.
-
+
hello.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
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
-looks suspicous, so let's tak a closer look. Remember that we can name
+looks suspicious, so let's take a closer look. Remember that we can name
it as master~3, HEAD~3, or any prefix of its commit identifier, (such
as 13ed136b):
commit 13ed136b983a9c439eddeea8a1c2076cffbb685f
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 13:15:43 2005 -0700
-
+
Introduce a typo into hello.c.
-
+
diff --git a/hello.c b/hello.c
index ed55ec0..80b260c 100644
--- a/hello.c
+++ b/hello.c
@@ -11,6 +11,6 @@
-
+
int main(int argc, char **argv)
{
- printf("hello, world!\n");
commit 13ed136b983a9c439eddeea8a1c2076cffbb685f
Author: Bryan O'Sullivan <bos@serpentine.com>
Date: Tue Sep 6 13:15:43 2005 -0700
-
+
Introduce a typo into hello.c.
-
+
diff --git a/hello.c b/hello.c
index ed55ec0..80b260c 100644
--- a/hello.c
+++ b/hello.c
@@ -11,6 +11,6 @@
-
+
int main(int argc, char **argv)
{
- printf("hello, world!\n");
After you've made that change, the “git status” command will tell you
what git knows about the files in the repository.
- $ ls
+ $ ls
hello.c Makefile
$ git status
# On branch master
--- a/hello.c
+++ b/hello.c
@@ -7,6 +7,6 @@
-
+
int main(int argc, char **argv)
{
- printf("hello, world!\");
then it will be there already). The initial contents of your
.gitconfig should look like this.
- # This is a git configuration file.
+ # This is a git configuration file.
[user]
name = Your Name
email = you@example.com
#### 2.7.3 Writing a good commit message
A good commit message will generally have a single line that
-summarizes the commit, a blank line, and then one or more pargraphs
+summarizes the commit, a blank line, and then one or more paragraphs
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.
$ git log --pretty=short
commit 3ef5535144da88a854f7930503845cd44506c2e2
Author: Censored Person <censored.person@example.org>
-
+
include buildmeister/commondefs. Add an exports and install
As far as the remainder of the contents of the commit message are
commit fd21e5d6c5eedee70137229ebf348c25181812ab
Author: Carl Worth <cworth@cworth.org>
Date: Fri Sep 28 12:50:16 2007 -0700
-
+
Fixed the typo so the program actuall complies now.
-
+
diff --git a/hello.c b/hello.c
index 9a3ff79..ea364d3 100644
--- a/hello.c
+++ b/hello.c
@@ -7,6 +7,6 @@
-
+
int main(int argc, char **argv)
{
- printf("hello, world!\");
commit 3c54ac672ec1130b36837f1b708054a7a1d402de
Author: Carl Worth <cworth@cworth.org>
Date: Fri Sep 28 12:50:16 2007 -0700
-
+
Fixed the typo so the program actually compiles now.
-
+
diff --git a/hello.c b/hello.c
index 9a3ff79..ea364d3 100644
--- a/hello.c
+++ b/hello.c
@@ -7,6 +7,6 @@
-
+
int main(int argc, char **argv)
{
- printf("hello, world!\");
the progress-tracking spew were reduced to a single line. Something
like "Computing (100%) Transferring (100%)" or whatever.
-After (lots!) of progresss indication, git gives a report of which
+After (lots!) of progress indication, git gives a report of which
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
commit 3c54ac672ec1130b36837f1b708054a7a1d402de
Author: Carl Worth <cworth@cworth.org>
Date: Fri Sep 28 12:50:16 2007 -0700
-
+
Fixed the typo so the program actually compiles now.
As expected, we received just the one commit.
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
-the previous section is conceptually the combination of two command,
+the previous section is conceptually the combination of two commands,
"git fetch" and "git merge". We can use these commands separately to
examine the change before accepting it.
commit 3c54ac672ec1130b36837f1b708054a7a1d402de
Author: Carl Worth <cworth@cworth.org>
Date: Fri Sep 28 12:50:16 2007 -0700
-
+
Fixed the typo so the program actually compiles now.
Another helpful way of visualizing what happened with "git fetch" here
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
-trashing filesystems then he might not want to push it out the the
+trashing filesystems then he might not want to push it out to the
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
## Appendix D
Open Publication License
-Version 1.0, 8 June 1999
+Version 1.0, 8 June 1999
### D.1 Requirements on both unmodified and modified versions
incorporation of it by reference (with any options elected by the
author(s) and/or publisher) is displayed in the reproduction.
-Proper form for an incorporation by reference is as follows:
+Proper form for an incorporation by reference is as follows:
Copyright (c) year by author’s name or designee. This material may be
distributed only subject to the terms and conditions set forth in the
translations, anthologies, compilations and partial documents, must
meet the following requirements:
- 1. The modified version must be labeled as such.
+ 1. The modified version must be labeled as such.
2. The person making the modifications must be identified and the
modifications dated.
3. Acknowledgement of the original author and publisher if
applicable must be retained according to normal academic citation
practices.
- 4. The location of the original unmodified document must be identified.
+ 4. The location of the original unmodified document must be identified.
5. The original author’s (or authors’) name(s) may not be used to
assert or imply endorsement of the resulting document without the
original author’s (or authors’) permission.