[git-svn PATCH] Fix markup in git-svn man page

[git-svn PATCH] Fix markup in git-svn man page

[Karl Hasselström]

Some of the existing markup was just plain broken, and some subcommand
options weren't indented properly.

Signed-off-by: Karl Hasselström <kha@treskal.com>
---

I poked at the markup with a stick until it rendered well (as both man
and html), but I really don't know much about asciidoc markup, so some
sanity-checking by a third party is probably a good idea.

 Documentation/git-svn.txt |   32 +++++++++++++-------------------
 1 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index fcdeeaa..c0d7d95 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -38,32 +38,30 @@ COMMANDS
 	argument.  Normally this command initializes the current
 	directory.
 
--T<trunk_subdir>::
---trunk=<trunk_subdir>::
--t<tags_subdir>::
---tags=<tags_subdir>::
--b<branches_subdir>::
---branches=<branches_subdir>::
+-T<trunk_subdir>;;
+--trunk=<trunk_subdir>;;
+-t<tags_subdir>;;
+--tags=<tags_subdir>;;
+-b<branches_subdir>;;
+--branches=<branches_subdir>;;
 	These are optional command-line options for init.  Each of
 	these flags can point to a relative repository path
 	(--tags=project/tags') or a full url
 	(--tags=https://foo.org/project/tags)
-
---no-metadata::
+--no-metadata;;
 	Set the 'noMetadata' option in the [svn-remote] config.
---use-svm-props::
+--use-svm-props;;
 	Set the 'useSvmProps' option in the [svn-remote] config.
---use-svnsync-props::
+--use-svnsync-props;;
 	Set the 'useSvnsyncProps' option in the [svn-remote] config.
---rewrite-root=<URL>::
+--rewrite-root=<URL>;;
 	Set the 'rewriteRoot' option in the [svn-remote] config.
---username=<USER>::
+--username=<USER>;;
 	For transports that SVN handles authentication for (http,
 	https, and plain svn), specify the username.  For other
 	transports (eg svn+ssh://), you must include the username in
 	the URL, eg svn+ssh://foo@svn.bar.com/project
-
---prefix=<prefix>::
+--prefix=<prefix>;;
 	This allows one to specify a prefix which is prepended
 	to the names of remotes if trunk/branches/tags are
 	specified.  The prefix does not automatically include a
@@ -73,7 +71,6 @@ COMMANDS
 	repository.
 
 'fetch'::
-
 	Fetch unfetched revisions from the Subversion remote we are
 	tracking.  The name of the [svn-remote "..."] section in the
 	.git/config file may be specified as an optional command-line
@@ -104,14 +101,11 @@ accepts.  However '--fetch-all' only fetches from the current
 
 Like 'git-rebase'; this requires that the working tree be clean
 and have no uncommitted changes.
-+
---
+
 -l;;
 --local;;
 	Do not fetch remotely; only run 'git-rebase' against the
 	last fetched commit from the upstream SVN.
---
-+
 
 'dcommit'::
 	Commit each diff from a specified head directly to the SVN

Re: [git-svn PATCH] Fix markup in git-svn man page

[Eric Wong]

Karl Hasselström <kha@treskal.com> wrote:
> Some of the existing markup was just plain broken, and some subcommand
> options weren't indented properly.
> 
> Signed-off-by: Karl Hasselström <kha@treskal.com>
> ---
> 
> I poked at the markup with a stick until it rendered well (as both man
> and html), but I really don't know much about asciidoc markup, so some
> sanity-checking by a third party is probably a good idea.

I don't know much about it, either.  They take way too long for me to
build, so I've mostly just guessed the syntax based on the existing
documentation and let other people fix it for me :)

-- 
Eric Wong

Re: [git-svn PATCH] Fix markup in git-svn man page

[Junio C Hamano]

Looks sane to me.  I did not know about double-semicolon, which
is mentioned in the user guide documentation at the asciidoc
site but I could not tell how it is different from double-colon
form.  I am guessing (from the behaviour after applying your
patch) that it allows second level of listing...

Re: [git-svn PATCH] Fix markup in git-svn man page

[Karl Hasselström]

On 2007-05-04 15:06:45 -0700, Junio C Hamano wrote:

> Looks sane to me. I did not know about double-semicolon, which is
> mentioned in the user guide documentation at the asciidoc site but I
> could not tell how it is different from double-colon form. I am
> guessing (from the behaviour after applying your patch) that it
> allows second level of listing...

Yes, it was used that way in the parts of the man page that already
looked OK, so I just copied it. If it looks good to you too, it must
be correct. :-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle