← Back to branch summary

~ubuntu-branches/ubuntu/intrepid/git-core/intrepid-updates

« back to all changes in this revision

Viewing changes to Documentation/tutorial-2.txt

  • Committer: Package Import Robot
  • Author(s): Gerrit Pape
  • Date: 2007-04-22 13:31:05 UTC
  • mfrom: (1.1.14)
  • Revision ID: package-import@ubuntu.com-20070422133105-tkmhz328g2p0epz1
Tags: 1:1.5.1.2-1
* new upstream point release.
* debian/changelog.upstream: upstream changes taken from mailing list
  announcement.

Show diffs side-by-side

added added

removed removed

Lines of Context:
Documentation/tutorial-2.txt
17
17
------------------------------------------------
18
18
$ mkdir test-project
19
19
$ cd test-project
20
 
$ git init-db
21
 
defaulting to local storage area
 
20
$ git init
 
21
Initialized empty Git repository in .git/
22
22
$ echo 'hello world' > file.txt
23
23
$ git add .
24
24
$ git commit -a -m "initial commit"
25
 
Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
 
25
Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
 
26
 create mode 100644 file.txt
26
27
$ echo 'hello world!' >file.txt
27
28
$ git commit -a -m "add emphasis"
 
29
Created commit c4d59f390b9cfd4318117afde11d601c1085f241
28
30
------------------------------------------------
29
31
 
30
 
What are the 40 digits of hex that git responded to the first commit
31
 
with?
 
32
What are the 40 digits of hex that git responded to the commit with?
32
33
 
33
34
We saw in part one of the tutorial that commits have names like this.
34
35
It turns out that every object in the git history is stored under
38
39
name), and that the contents of a git object will never change (since
39
40
that would change the object's name as well).
40
41
 
 
42
It is expected that the content of the commit object you created while
 
43
following the example above generates a different SHA1 hash than
 
44
the one shown above because the commit object records the time when
 
45
it was created and the name of the person performing the commit.
 
46
 
41
47
We can ask git about this particular object with the cat-file
42
 
command--just cut-and-paste from the reply to the initial commit, to
43
 
save yourself typing all 40 hex digits:
 
48
command. Don't copy the 40 hex digits from this example but use those
 
49
from your own version. Note that you can shorten it to only a few
 
50
characters to save yourself typing all 40 hex digits:
44
51
 
45
52
------------------------------------------------
46
 
$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe
47
 
tree
 
53
$ git-cat-file -t 54196cc2
 
54
commit
 
55
$ git-cat-file commit 54196cc2
 
56
tree 92b8b694ffb1675e5975148e1121810081dbdffe
 
57
author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
 
58
committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
 
59
 
 
60
initial commit
48
61
------------------------------------------------
49
62
 
50
63
A tree can refer to one or more "blob" objects, each corresponding to
101
114
 
102
115
and the contents of these files is just the compressed data plus a
103
116
header identifying their length and their type.  The type is either a
104
 
blob, a tree, a commit, or a tag.  We've seen a blob and a tree now,
105
 
so next we should look at a commit.
 
117
blob, a tree, a commit, or a tag.
106
118
 
107
119
The simplest commit to find is the HEAD commit, which we can find
108
120
from .git/HEAD:
215
227
@@ -1 +1,2 @@
216
228
 hello world!
217
229
+hello world, again
218
 
$ git update-index file.txt
 
230
$ git add file.txt
219
231
$ git diff
220
232
------------------------------------------------
221
233
 
248
260
hello world, again
249
261
------------------------------------------------
250
262
 
251
 
So what our "git update-index" did was store a new blob and then put
 
263
So what our "git add" did was store a new blob and then put
252
264
a reference to it in the index file.  If we modify the file again,
253
265
we'll see that the new modifications are reflected in the "git-diff"
254
266
output:
331
343
current contents of the file:
332
344
 
333
345
------------------------------------------------
334
 
$ git cat-file blob a6b11f7a
335
 
goodbye, word
 
346
$ git cat-file blob 8b9743b2
 
347
goodbye, world
336
348
------------------------------------------------
337
349
 
338
350
The "status" command is a useful way to get a quick summary of the
340
352
 
341
353
------------------------------------------------
342
354
$ git status
343
 
#
344
 
# Updated but not checked in:
345
 
#   (will commit)
 
355
# On branch master
 
356
# Changes to be committed:
 
357
#   (use "git reset HEAD <file>..." to unstage)
346
358
#
347
359
#       new file: closing.txt
348
360
#
349
 
#
350
361
# Changed but not updated:
351
 
#   (use git-update-index to mark for commit)
 
362
#   (use "git add <file>..." to update what will be committed)
352
363
#
353
364
#       modified: file.txt
354
365
#
355
366
------------------------------------------------
356
367
 
357
368
Since the current state of closing.txt is cached in the index file,
358
 
it is listed as "updated but not checked in".  Since file.txt has
 
369
it is listed as "Changes to be committed".  Since file.txt has
359
370
changes in the working directory that aren't reflected in the index,
360
371
it is marked "changed but not updated".  At this point, running "git
361
372
commit" would create a commit that added closing.txt (with its new