Documentation/howto: convert plain text files to asciidoc
These were not originally meant for asciidoc, but they are already so close. Mark them up in asciidoc. Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Ackermann committed
Oct 16, 2012 at 19:25 UTC
1797e5c50c00b514b798f7b0441c86ee71fb0fab
11 files changed
+68
-32
Documentation/howto/maintain-git.txt
+4
@@ -5,6 +5,10 @@ Abstract: Imagine that git development is racing along as usual, when our friend
5
neighborhood maintainer is struck down by a wayward bus. Out of the
6
hordes of suckers (loyal developers), you have been tricked (chosen) to
7
step up as the new maintainer. This howto will show you "how to" do it.
8
+Content-type: text/asciidoc
9
+
10
+How to maintain Git
11
+===================
12
13
The maintainer's git time is spent on three activities.
14
Documentation/howto/rebase-from-internal-branch.txt
+6
-5
@@ -8,7 +8,12 @@ Abstract: In this article, JC talks about how he rebases the
8
the "master" branch, and how "rebase" works. Also discussed
9
is how this applies to individual developers who sends patches
10
upstream.
11
+Content-type: text/asciidoc
12
13
+How to rebase from an internal branch
14
+=====================================
15
+
16
+--------------------------------------
17
Petr Baudis <pasky@suse.cz> writes:
18
19
> 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:
24
>> > branch to the real branches.
25
>>
26
> Actually, wouldn't this be also precisely for what StGIT is intended to?
27
+--------------------------------------
28
29
Exactly my feeling. I was sort of waiting for Catalin to speak
30
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
162
the #1' commit.
163
164
-jc
159
-
160
--
161
-To unsubscribe from this list: send the line "unsubscribe git" in
162
-the body of a message to majordomo@vger.kernel.org
163
-More majordomo info at http://vger.kernel.org/majordomo-info.html
Documentation/howto/rebuild-from-update-hook.txt
+4
@@ -5,6 +5,10 @@ Date: Fri, 26 Aug 2005 18:19:10 -0700
5
Abstract: In this how-to article, JC talks about how he
6
uses the post-update hook to automate git documentation page
7
shown at http://www.kernel.org/pub/software/scm/git/docs/.
8
+Content-type: text/asciidoc
9
+
10
+How to rebuild from update hook
11
+===============================
12
13
The pages under http://www.kernel.org/pub/software/scm/git/docs/
14
are built from Documentation/ directory of the git.git project
Documentation/howto/recover-corrupted-blob-object.txt
+10
@@ -3,11 +3,17 @@ From: Linus Torvalds <torvalds@linux-foundation.org>
3
Subject: corrupt object on git-gc
4
Abstract: Some tricks to reconstruct blob objects in order to fix
5
a corrupted repository.
6
+Content-type: text/asciidoc
7
8
+How to recover a corrupted blob object
9
+======================================
10
+
11
+-----------------------------------------------------------
12
On Fri, 9 Nov 2007, Yossi Leybovich wrote:
13
>
14
> Did not help still the repository look for this object?
15
> Any one know how can I track this object and understand which file is it
16
+-----------------------------------------------------------
17
18
So exactly *because* the SHA1 hash is cryptographically secure, the hash
19
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
37
interesting for the future, in the hope that you can re-create a
38
non-corrupt version.
39
40
+-----------------------------------------------------------
41
So:
42
43
> ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../
44
+-----------------------------------------------------------
45
46
This is the right thing to do, although it's usually best to save it under
47
it's full SHA1 name (you just dropped the "4b" from the result ;).
48
49
Let's see what that tells us:
50
51
+-----------------------------------------------------------
52
> ib]$ git-fsck --full
53
> broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
54
> to blob 4b9458b3786228369c63936db65827de3cc06200
55
> missing blob 4b9458b3786228369c63936db65827de3cc06200
56
+-----------------------------------------------------------
57
58
Ok, I removed the "dangling commit" messages, because they are just
59
messages about the fact that you probably have rebased etc, so they're not
Documentation/howto/revert-a-faulty-merge.txt
+4
@@ -7,6 +7,10 @@ Abstract: Sometimes a branch that was already merged to the mainline
7
after the offending branch is fixed.
8
Message-ID: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org>
9
References: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain>
10
+Content-type: text/asciidoc
11
+
12
+How to revert a faulty merge
13
+============================
14
15
Alan <alan@clueserver.org> said:
16
Documentation/howto/revert-branch-rebase.txt
+2
-2
@@ -8,8 +8,8 @@ Date: Mon, 29 Aug 2005 21:39:02 -0700
8
Content-type: text/asciidoc
9
Message-ID: <7voe7g3uop.fsf@assigned-by-dhcp.cox.net>
10
11
-Reverting an existing commit
12
-============================
11
+How to revert an existing commit
12
+================================
13
14
One of the changes I pulled into the 'master' branch turns out to
15
break building GIT with GCC 2.95. While they were well intentioned
Documentation/howto/separating-topic-branches.txt
+4
@@ -1,6 +1,10 @@
1
From: Junio C Hamano <gitster@pobox.com>
2
Subject: Separating topic branches
3
Abstract: In this article, JC describes how to separate topic branches.
4
+Content-type: text/asciidoc
5
+
6
+How to separate topic branches
7
+==============================
8
9
This text was originally a footnote to a discussion about the
10
behaviour of the git diff commands.
Documentation/howto/setup-git-server-over-http.txt
+4
@@ -1,6 +1,10 @@
1
From: Rutger Nijlunsing <rutger@nospam.com>
2
Subject: Setting up a git repository which can be pushed into and pulled from over HTTP(S).
3
Date: Thu, 10 Aug 2006 22:00:26 +0200
4
+Content-type: text/asciidoc
5
+
6
+How to setup git server over http
7
+=================================
8
9
Since Apache is one of those packages people like to compile
10
themselves while others prefer the bureaucrat's dream Debian, it is
Documentation/howto/update-hook-example.txt
renamed
+25
-23
@@ -5,6 +5,10 @@ Message-ID: <7vfypumlu3.fsf@assigned-by-dhcp.cox.net>
5
Abstract: An example hooks/update script is presented to
6
implement repository maintenance policies, such as who can push
7
into which branch and who can make a tag.
8
+Content-type: text/asciidoc
9
+
10
+How to use the update hook
11
+==========================
12
13
When your developer runs git-push into the repository,
14
git-receive-pack is run (either locally or over ssh) as that
@@ -32,8 +36,7 @@ like this as your hooks/update script.
36
[jc: editorial note. This is a much improved version by Carl
37
since I posted the original outline]
38
35
-
39
+----------------------------------------------------
40
#!/bin/bash
41
42
umask 002
@@ -111,12 +114,12 @@ then
114
115
info "Found matching head pattern: '$head_pattern'"
116
for user_pattern in $user_patterns; do
114
- info "Checking user: '$username' against pattern: '$user_pattern'"
115
- matchlen=$(expr "$username" : "$user_pattern")
116
- if test "$matchlen" = "${#username}"
117
- then
118
- grant "Allowing user: '$username' with pattern: '$user_pattern'"
119
- fi
117
+ info "Checking user: '$username' against pattern: '$user_pattern'"
118
+ matchlen=$(expr "$username" : "$user_pattern")
119
+ if test "$matchlen" = "${#username}"
120
+ then
121
+ grant "Allowing user: '$username' with pattern: '$user_pattern'"
122
+ fi
123
done
124
deny "The user is not in the access list for this branch"
125
done
@@ -149,13 +152,13 @@ then
152
153
info "Found matching head pattern: '$head_pattern'"
154
for group_pattern in $group_patterns; do
152
- for groupname in $groups; do
153
- info "Checking group: '$groupname' against pattern: '$group_pattern'"
154
- matchlen=$(expr "$groupname" : "$group_pattern")
155
- if test "$matchlen" = "${#groupname}"
156
- then
157
- grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
158
- fi
155
+ for groupname in $groups; do
156
+ info "Checking group: '$groupname' against pattern: '$group_pattern'"
157
+ matchlen=$(expr "$groupname" : "$group_pattern")
158
+ if test "$matchlen" = "${#groupname}"
159
+ then
160
+ grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
161
+ fi
162
done
163
done
164
deny "None of the user's groups are in the access list for this branch"
@@ -169,24 +172,21 @@ then
172
fi
173
174
deny >/dev/null "There are no more rules to check. Denying access"
172
-
175
+----------------------------------------------------
176
177
This uses two files, $GIT_DIR/info/allowed-users and
178
allowed-groups, to describe which heads can be pushed into by
179
whom. The format of each file would look like this:
180
178
- refs/heads/master junio
179
- +refs/heads/pu junio
180
- refs/heads/cogito$ pasky
181
- refs/heads/bw/.* linus
182
- refs/heads/tmp/.* .*
183
- refs/tags/v[0-9].* junio
181
+ refs/heads/master junio
182
+ +refs/heads/pu junio
183
+ refs/heads/cogito$ pasky
184
+ refs/heads/bw/.* linus
185
+ refs/heads/tmp/.* .*
186
+ refs/tags/v[0-9].* junio
187
188
With this, Linus can push or create "bw/penguin" or "bw/zebra"
189
or "bw/panda" branches, Pasky can do only "cogito", and JC can
190
do master and pu branches and make versioned tags. And anybody
191
can do tmp/blah branches. The '+' sign at the pu record means
192
that JC can make non-fast-forward pushes on it.
190
-
191
-------------
Documentation/howto/use-git-daemon.txt
+3
@@ -1,4 +1,7 @@
1
+Content-type: text/asciidoc
2
+
3
How to use git-daemon
4
+=====================
5
6
Git can be run in inetd mode and in stand alone mode. But all you want is
7
let a coworker pull from you, and therefore need to set up a git server
Documentation/howto/using-signed-tag-in-pull-request.txt
+2
-2
@@ -7,8 +7,8 @@ Abstract: Beginning v1.7.9, a contributor can push a signed tag to her
7
later validate it.
8
Content-type: text/asciidoc
9
10
-Using signed tag in pull requests
11
-=================================
10
+How to use a signed tag in pull requests
11
+========================================
12
13
A typical distributed workflow using Git is for a contributor to fork a
14
project, build on it, publish the result to her public repository, and ask