Skip to content

Commit 915cd9b

Browse files
author
Junio C Hamano
committed
Autogenerated HTML docs for v1.5.6.4-433-g09651
1 parent f69a0a0 commit 915cd9b

16 files changed

Lines changed: 338 additions & 216 deletions

‎RelNotes-1.5.6.4.txt‎

Lines changed: 10 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -28,16 +28,20 @@ Fixes since v1.5.6.3
2828
be huge by saying "no common commits", but this was an unnecessary
2929
noise; it is already known by the user anyway.
3030

31+
* "git-http-fetch" would have segfaulted when pack idx file retrieved
32+
from the other side was corrupt.
33+
34+
* "git-index-pack" used too much memory when dealing with a deep delta chain.
35+
3136
* "git-mailinfo" (hence "git-am") did not correctly handle in-body [PATCH]
3237
line to override the commit title taken from the mail Subject header.
3338

3439
* "git-rebase -i -p" lost parents that are not involved in the history
3540
being rewritten.
3641

37-
Contains other various documentation fixes.
42+
* "git-rm" lost track of where the index file was when GIT_DIR was
43+
specified as a relative path.
3844

39-
--
40-
exec >/var/tmp/1
41-
echo O=$(git describe maint)
42-
O=v1.5.6.3-21-gebcce31
43-
git shortlog --no-merges $O..maint
45+
* "git-rev-list --quiet" was not quiet as advertised.
46+
47+
Contains other various documentation fixes.

‎RelNotes-1.6.0.txt‎

Lines changed: 11 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,9 @@ main git.git codebase.
2121
By default, packfiles created with this version uses delta-base-offset
2222
encoding introduced in v1.4.4. Pack idx files are using version 2 that
2323
allows larger packs and added robustness thanks to its CRC checking,
24-
introduced in v1.5.2.
24+
introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories
25+
backwards compatible past these versions, set repack.useDeltaBaseOffset
26+
to false or pack.indexVersion to 1, respectively.
2527

2628
GIT_CONFIG, which was only documented as affecting "git config", but
2729
actually affected all git commands, now only affects "git config".
@@ -134,6 +136,9 @@ Updates since v1.5.6
134136
* git-archive can be told to omit certain paths from its output using
135137
export-ignore attributes.
136138

139+
* git-archive uses the zlib default compression level when creating
140+
zip archive.
141+
137142
* With -v option, git-branch describes the remote tracking statistics
138143
similar to the way git-checkout reports by how many commits your branch
139144
is ahead/behind.
@@ -153,6 +158,8 @@ Updates since v1.5.6
153158
* git-clone can clone from a remote whose URL would be rewritten by
154159
configuration stored in $HOME/.gitconfig now.
155160

161+
* git-cvsserver learned to respond to "cvs co -c".
162+
156163
* git-diff --check now checks leftover merge conflict markers.
157164

158165
* When remote side used to have branch 'foo' and git-fetch finds that now
@@ -164,6 +171,8 @@ Updates since v1.5.6
164171
* fast-export learned to export and import marks file; this can be used to
165172
interface with fast-import incrementally.
166173

174+
* fast-import and fast-export learned to export and import gitlinks.
175+
167176
* git-rebase records the original tip of branch in ORIG_HEAD before it is
168177
rewound.
169178

@@ -208,6 +217,6 @@ this release, unless otherwise noted.
208217

209218
---
210219
exec >/var/tmp/1
211-
O=v1.5.6.3-436-g1f8dc67
220+
O=v1.5.6.4-432-g6796399
212221
echo O=$(git describe refs/heads/master)
213222
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint

‎git-fast-import.html‎

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -875,6 +875,13 @@ <h4 id="_tt_filemodify_tt"><tt>filemodify</tt></h4>
875875
<tt>120000</tt>: A symlink, the content of the file will be the link target.
876876
</p>
877877
</li>
878+
<li>
879+
<p>
880+
<tt>160000</tt>: A gitlink, SHA-1 of the object refers to a commit in
881+
another repository. Git links can only be specified by SHA or through
882+
a commit mark. They are used to implement submodules.
883+
</p>
884+
</li>
878885
</ul></div>
879886
<div class="para"><p>In both formats <tt>&lt;path&gt;</tt> is the complete path of the file to be added
880887
(if not already existing) or modified (if already existing).</p></div>
@@ -1464,7 +1471,7 @@ <h2 id="_git">GIT</h2>
14641471
</div>
14651472
<div id="footer">
14661473
<div id="footer-text">
1467-
Last updated 2008-07-06 05:16:45 UTC
1474+
Last updated 2008-07-20 01:23:33 UTC
14681475
</div>
14691476
</div>
14701477
</body>

‎git-fast-import.txt‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -481,6 +481,9 @@ in octal. Git only supports the following modes:
481481
what you want.
482482
* `100755` or `755`: A normal, but executable, file.
483483
* `120000`: A symlink, the content of the file will be the link target.
484+
* `160000`: A gitlink, SHA-1 of the object refers to a commit in
485+
another repository. Git links can only be specified by SHA or through
486+
a commit mark. They are used to implement submodules.
484487

485488
In both formats `<path>` is the complete path of the file to be added
486489
(if not already existing) or modified (if already existing).

‎git-merge.html‎

Lines changed: 40 additions & 50 deletions
Original file line numberDiff line numberDiff line change
@@ -657,52 +657,41 @@ <h2 id="_how_merge_works">HOW MERGE WORKS</h2>
657657
<div class="sectionbody">
658658
<div class="para"><p>A merge is always between the current <tt>HEAD</tt> and one or more
659659
commits (usually, branch head or tag), and the index file must
660-
exactly match the
661-
tree of <tt>HEAD</tt> commit (i.e. the contents of the last commit) when
662-
it happens. In other words, <tt>git diff --cached HEAD</tt> must
663-
report no changes.</p></div>
664-
<div class="admonitionblock">
665-
<table><tr>
666-
<td class="icon">
667-
<div class="title">Note</div>
668-
</td>
669-
<td class="content">This is a bit of a lie. In certain special cases, your index is
670-
allowed to be different from the tree of the <tt>HEAD</tt> commit. The most
671-
notable case is when your <tt>HEAD</tt> commit is already ahead of what
672-
is being merged, in which case your index can have arbitrary
673-
differences from your <tt>HEAD</tt> commit. Also, your index entries
674-
may have differences from your <tt>HEAD</tt> commit that match
675-
the result of a trivial merge (e.g. you received the same patch
676-
from an external source to produce the same result as what you are
677-
merging). For example, if a path did not exist in the common
678-
ancestor and your head commit but exists in the tree you are
679-
merging into your repository, and if you already happen to have
680-
that path exactly in your index, the merge does not have to
681-
fail.</td>
682-
</tr></table>
683-
</div>
684-
<div class="para"><p>Otherwise, merge will refuse to do any harm to your repository
685-
(that is, it may fetch the objects from remote, and it may even
686-
update the local branch used to keep track of the remote branch
687-
with <tt>git pull remote rbranch:lbranch</tt>, but your working tree,
688-
<tt>.git/HEAD</tt> pointer and index file are left intact). In addition,
689-
merge always sets <tt>.git/ORIG_HEAD</tt> to the original state of HEAD so
690-
a problematic merge can be removed by using <tt>git reset ORIG_HEAD</tt>.</p></div>
691-
<div class="para"><p>You may have local modifications in the working tree files. In
692-
other words, <em>git-diff</em> is allowed to report changes.
693-
However, the merge uses your working tree as the working area,
694-
and in order to prevent the merge operation from losing such
695-
changes, it makes sure that they do not interfere with the
696-
merge. Those complex tables in read-tree documentation define
697-
what it means for a path to "interfere with the merge". And if
698-
your local modifications interfere with the merge, again, it
699-
stops before touching anything.</p></div>
700-
<div class="para"><p>So in the above two "failed merge" case, you do not have to
701-
worry about loss of data --- you simply were not ready to do
702-
a merge, so no merge happened at all. You may want to finish
703-
whatever you were in the middle of doing, and retry the same
704-
pull after you are done and ready.</p></div>
705-
<div class="para"><p>When things cleanly merge, these things happen:</p></div>
660+
match the tree of <tt>HEAD</tt> commit (i.e. the contents of the last commit)
661+
when it starts out. In other words, <tt>git diff --cached HEAD</tt> must
662+
report no changes. (One exception is when the changed index
663+
entries are already in the same state that would result from
664+
the merge anyway.)</p></div>
665+
<div class="para"><p>Three kinds of merge can happen:</p></div>
666+
<div class="ilist"><ul>
667+
<li>
668+
<p>
669+
The merged commit is already contained in <tt>HEAD</tt>. This is the
670+
simplest case, called "Already up-to-date."
671+
</p>
672+
</li>
673+
<li>
674+
<p>
675+
<tt>HEAD</tt> is already contained in the merged commit. This is the
676+
most common case especially when involved through <em>git pull</em>:
677+
you are tracking an upstream repository, committed no local
678+
changes and now you want to update to a newer upstream revision.
679+
Your <tt>HEAD</tt> (and the index) is updated to at point the merged
680+
commit, without creating an extra merge commit. This is
681+
called "Fast-forward".
682+
</p>
683+
</li>
684+
<li>
685+
<p>
686+
Both the merged commit and <tt>HEAD</tt> are independent and must be
687+
tied together by a merge commit that has them both as its parents.
688+
The rest of this section describes this "True merge" case.
689+
</p>
690+
</li>
691+
</ul></div>
692+
<div class="para"><p>The chosen merge strategy merges the two commits into a single
693+
new source tree.
694+
When things cleanly merge, these things happen:</p></div>
706695
<div class="olist"><ol>
707696
<li>
708697
<p>
@@ -773,15 +762,16 @@ <h2 id="_how_merge_works">HOW MERGE WORKS</h2>
773762
<p>
774763
Decide not to merge. The only clean-up you need are to reset
775764
the index file to the <tt>HEAD</tt> commit to reverse 2. and to clean
776-
up working tree changes made by 2. and 3.; <em>git-reset</em> can
765+
up working tree changes made by 2. and 3.; <em>git-reset --hard</em> can
777766
be used for this.
778767
</p>
779768
</li>
780769
<li>
781770
<p>
782771
Resolve the conflicts. <tt>git diff</tt> would report only the
783-
conflicting paths because of the above 2. and 3. Edit the
784-
working tree files into a desirable shape, <em>git-add</em> or <em>git-rm</em>
772+
conflicting paths because of the above 2. and 3.
773+
Edit the working tree files into a desirable shape
774+
(<em>git mergetool</em> can ease this task), <em>git-add</em> or <em>git-rm</em>
785775
them, to make the index file contain what the merge result
786776
should be, and run <em>git-commit</em> to commit the result.
787777
</p>
@@ -811,7 +801,7 @@ <h2 id="_git">GIT</h2>
811801
</div>
812802
<div id="footer">
813803
<div id="footer-text">
814-
Last updated 2008-07-15 15:48:34 UTC
804+
Last updated 2008-07-20 01:23:33 UTC
815805
</div>
816806
</div>
817807
</body>

‎git-merge.txt‎

Lines changed: 29 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -57,50 +57,31 @@ HOW MERGE WORKS
5757

5858
A merge is always between the current `HEAD` and one or more
5959
commits (usually, branch head or tag), and the index file must
60-
exactly match the
61-
tree of `HEAD` commit (i.e. the contents of the last commit) when
62-
it happens. In other words, `git diff --cached HEAD` must
63-
report no changes.
64-
65-
[NOTE]
66-
This is a bit of a lie. In certain special cases, your index is
67-
allowed to be different from the tree of the `HEAD` commit. The most
68-
notable case is when your `HEAD` commit is already ahead of what
69-
is being merged, in which case your index can have arbitrary
70-
differences from your `HEAD` commit. Also, your index entries
71-
may have differences from your `HEAD` commit that match
72-
the result of a trivial merge (e.g. you received the same patch
73-
from an external source to produce the same result as what you are
74-
merging). For example, if a path did not exist in the common
75-
ancestor and your head commit but exists in the tree you are
76-
merging into your repository, and if you already happen to have
77-
that path exactly in your index, the merge does not have to
78-
fail.
79-
80-
Otherwise, merge will refuse to do any harm to your repository
81-
(that is, it may fetch the objects from remote, and it may even
82-
update the local branch used to keep track of the remote branch
83-
with `git pull remote rbranch:lbranch`, but your working tree,
84-
`.git/HEAD` pointer and index file are left intact). In addition,
85-
merge always sets `.git/ORIG_HEAD` to the original state of HEAD so
86-
a problematic merge can be removed by using `git reset ORIG_HEAD`.
87-
88-
You may have local modifications in the working tree files. In
89-
other words, 'git-diff' is allowed to report changes.
90-
However, the merge uses your working tree as the working area,
91-
and in order to prevent the merge operation from losing such
92-
changes, it makes sure that they do not interfere with the
93-
merge. Those complex tables in read-tree documentation define
94-
what it means for a path to "interfere with the merge". And if
95-
your local modifications interfere with the merge, again, it
96-
stops before touching anything.
97-
98-
So in the above two "failed merge" case, you do not have to
99-
worry about loss of data --- you simply were not ready to do
100-
a merge, so no merge happened at all. You may want to finish
101-
whatever you were in the middle of doing, and retry the same
102-
pull after you are done and ready.
103-
60+
match the tree of `HEAD` commit (i.e. the contents of the last commit)
61+
when it starts out. In other words, `git diff --cached HEAD` must
62+
report no changes. (One exception is when the changed index
63+
entries are already in the same state that would result from
64+
the merge anyway.)
65+
66+
Three kinds of merge can happen:
67+
68+
* The merged commit is already contained in `HEAD`. This is the
69+
simplest case, called "Already up-to-date."
70+
71+
* `HEAD` is already contained in the merged commit. This is the
72+
most common case especially when involved through 'git pull':
73+
you are tracking an upstream repository, committed no local
74+
changes and now you want to update to a newer upstream revision.
75+
Your `HEAD` (and the index) is updated to at point the merged
76+
commit, without creating an extra merge commit. This is
77+
called "Fast-forward".
78+
79+
* Both the merged commit and `HEAD` are independent and must be
80+
tied together by a merge commit that has them both as its parents.
81+
The rest of this section describes this "True merge" case.
82+
83+
The chosen merge strategy merges the two commits into a single
84+
new source tree.
10485
When things cleanly merge, these things happen:
10586

10687
1. The results are updated both in the index file and in your
@@ -142,12 +123,13 @@ After seeing a conflict, you can do two things:
142123

143124
* Decide not to merge. The only clean-up you need are to reset
144125
the index file to the `HEAD` commit to reverse 2. and to clean
145-
up working tree changes made by 2. and 3.; 'git-reset' can
126+
up working tree changes made by 2. and 3.; 'git-reset --hard' can
146127
be used for this.
147128

148129
* Resolve the conflicts. `git diff` would report only the
149-
conflicting paths because of the above 2. and 3. Edit the
150-
working tree files into a desirable shape, 'git-add' or 'git-rm'
130+
conflicting paths because of the above 2. and 3.
131+
Edit the working tree files into a desirable shape
132+
('git mergetool' can ease this task), 'git-add' or 'git-rm'
151133
them, to make the index file contain what the merge result
152134
should be, and run 'git-commit' to commit the result.
153135

0 commit comments

Comments
 (0)