* ta/doc-cleanup:
Documentation: build html for all files in technical and howto
Documentation/howto: convert plain text files to asciidoc
Documentation/technical: convert plain text files to asciidoc
Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
Split over-long synopsis in git-fetch-pack.txt into several lines
@ -5,6 +5,10 @@ Abstract: Imagine that git development is racing along as usual, when our friend
@@ -5,6 +5,10 @@ Abstract: Imagine that git development is racing along as usual, when our friend
neighborhood maintainer is struck down by a wayward bus. Out of the
hordes of suckers (loyal developers), you have been tricked (chosen) to
step up as the new maintainer. This howto will show you "how to" do it.
Content-type: text/asciidoc
How to maintain Git
===================
The maintainer's git time is spent on three activities.
@ -8,7 +8,12 @@ Abstract: In this article, JC talks about how he rebases the
@@ -8,7 +8,12 @@ Abstract: In this article, JC talks about how he rebases the
the "master" branch, and how "rebase" works. Also discussed
is how this applies to individual developers who sends patches
upstream.
Content-type: text/asciidoc
How to rebase from an internal branch
=====================================
--------------------------------------
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
@ -19,6 +24,7 @@ Petr Baudis <pasky@suse.cz> writes:
@@ -19,6 +24,7 @@ Petr Baudis <pasky@suse.cz> writes:
>> > branch to the real branches.
>>
> Actually, wouldn't this be also precisely for what StGIT is intended to?
--------------------------------------
Exactly my feeling. I was sort of waiting for Catalin to speak
up. With its basing philosophical ancestry on quilt, this is
@ -156,8 +162,3 @@ you continue on starting from the new "master" head, which is
@@ -156,8 +162,3 @@ you continue on starting from the new "master" head, which is
the #1' commit.
-jc
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
So exactly *because* the SHA1 hash is cryptographically secure, the hash
itself doesn't actually tell you anything, in order to fix a corrupt
@ -31,19 +37,23 @@ original object, so right now the corrupt object is useless, but it's very
@@ -31,19 +37,23 @@ original object, so right now the corrupt object is useless, but it's very
interesting for the future, in the hope that you can re-create a
@ -7,6 +7,10 @@ Abstract: Sometimes a branch that was already merged to the mainline
@@ -7,6 +7,10 @@ Abstract: Sometimes a branch that was already merged to the mainline
@ -7,8 +7,8 @@ Abstract: Beginning v1.7.9, a contributor can push a signed tag to her
@@ -7,8 +7,8 @@ Abstract: Beginning v1.7.9, a contributor can push a signed tag to her
later validate it.
Content-type: text/asciidoc
Using signed tag in pull requests
=================================
How to use a signed tag in pull requests
========================================
A typical distributed workflow using Git is for a contributor to fork a
project, build on it, publish the result to her public repository, and ask
@ -117,7 +117,7 @@ A few things to remember here:
@@ -117,7 +117,7 @@ A few things to remember here:
- The repository path is always quoted with single quotes.
Fetching Data From a Server
===========================
---------------------------
When one Git repository wants to get data that a second repository
has, the first can 'fetch' from the second. This operation determines
@ -134,7 +134,8 @@ with the object name that each reference currently points to.
@@ -134,7 +134,8 @@ with the object name that each reference currently points to.
@ -74,24 +74,24 @@ For multiple ancestors, a '+' means that this case applies even if
@@ -74,24 +74,24 @@ For multiple ancestors, a '+' means that this case applies even if
only one ancestor or remote fits; a '^' means all of the ancestors
must be the same.
case ancest head remote result
----------------------------------------
1 (empty)+ (empty) (empty) (empty)
2ALT (empty)+ *empty* remote remote
2 (empty)^ (empty) remote no merge
3ALT (empty)+ head *empty* head
3 (empty)^ head (empty) no merge
4 (empty)^ head remote no merge
5ALT * head head head
6 ancest+ (empty) (empty) no merge
8 ancest^ (empty) ancest no merge
7 ancest+ (empty) remote no merge
10 ancest^ ancest (empty) no merge
9 ancest+ head (empty) no merge
16 anc1/anc2 anc1 anc2 no merge
13 ancest+ head ancest head
14 ancest+ ancest remote remote
11 ancest+ head remote no merge
case ancest head remote result
----------------------------------------
1 (empty)+ (empty) (empty) (empty)
2ALT (empty)+ *empty* remote remote
2 (empty)^ (empty) remote no merge
3ALT (empty)+ head *empty* head
3 (empty)^ head (empty) no merge
4 (empty)^ head remote no merge
5ALT * head head head
6 ancest+ (empty) (empty) no merge
8 ancest^ (empty) ancest no merge
7 ancest+ (empty) remote no merge
10 ancest^ ancest (empty) no merge
9 ancest+ head (empty) no merge
16 anc1/anc2 anc1 anc2 no merge
13 ancest+ head ancest head
14 ancest+ ancest remote remote
11 ancest+ head remote no merge
Only #2ALT and #3ALT use *empty*, because these are the only cases
where there can be conflicts that didn't exist before. Note that we