From: Sergey Vlasov <vsu@altlinux.ru>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org, Sergey Vlasov <vsu@altlinux.ru>
Subject: [PATCH 4/4] Documentation/git-svn.txt: Fix formatting errors
Date: Thu, 1 Mar 2007 22:41:17 +0300 [thread overview]
Message-ID: <11727781092949-git-send-email-vsu@altlinux.ru> (raw)
In-Reply-To: <11727780982140-git-send-email-vsu@altlinux.ru>
Fix some formatting problems:
- Some list labels were missing their "::" characters.
- Some of continuation paragraphs in labeled lists were incorrectly
formatted as literal paragraphs.
- In one case "[verse]" was missing before the config key list.
- The "Basic Examples" section was incorrectly nested inside the
"Config File-Only Options" section.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Cc: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-svn.txt | 119 +++++++++++++++++++++++++--------------------
1 files changed, 67 insertions(+), 52 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index cf094ca..06b49b0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -63,7 +63,7 @@ COMMANDS
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
@@ -94,16 +94,16 @@ COMMANDS
This fetches revisions from the SVN parent of the current HEAD
and rebases the current (uncommitted to SVN) work against it.
- This works similarly to 'svn update' or 'git-pull' except that
- it preserves linear history with 'git-rebase' instead of
- 'git-merge' for ease of dcommit-ing with git-svn.
+This works similarly to 'svn update' or 'git-pull' except that
+it preserves linear history with 'git-rebase' instead of
+'git-merge' for ease of dcommit-ing with git-svn.
- This accepts all options that 'git-svn fetch' and 'git-rebase'
- accepts. However '--fetch-all' only fetches from the current
- [svn-remote], and not all [svn-remote] definitions.
+This accepts all options that 'git-svn fetch' and 'git-rebase'
+accepts. However '--fetch-all' only fetches from the current
+[svn-remote], and not all [svn-remote] definitions.
- Like 'git-rebase'; this requires that the working tree be clean
- and have no uncommitted changes.
+Like 'git-rebase'; this requires that the working tree be clean
+and have no uncommitted changes.
'dcommit'::
Commit each diff from a specified head directly to the SVN
@@ -117,29 +117,40 @@ COMMANDS
alternative to HEAD.
This is advantageous over 'set-tree' (below) because it produces
cleaner, more linear history.
+--
'log'::
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
++
+The following features from `svn log' are supported:
++
+--
+--revision=<n>[:<n>];;
+ is supported, non-numeric args are not:
+ HEAD, NEXT, BASE, PREV, etc ...
+-v/--verbose;;
+ it's not completely compatible with the --verbose
+ output in svn log, but reasonably close.
+--limit=<n>;;
+ is NOT the same as --max-count, doesn't count
+ merged/excluded commits
+--incremental;;
+ supported
+--
++
+New features:
++
+--
+--show-commit;;
+ shows the git commit sha1, as well
+--oneline;;
+ our version of --pretty=oneline
+--
++
+Any other arguments are passed directly to `git log'
- The following features from `svn log' are supported:
-
- --revision=<n>[:<n>] - is supported, non-numeric args are not:
- HEAD, NEXT, BASE, PREV, etc ...
- -v/--verbose - it's not completely compatible with
- the --verbose output in svn log, but
- reasonably close.
- --limit=<n> - is NOT the same as --max-count,
- doesn't count merged/excluded commits
- --incremental - supported
-
- New features:
-
- --show-commit - shows the git commit sha1, as well
- --oneline - our version of --pretty=oneline
-
- Any other arguments are passed directly to `git log'
-
+--
'set-tree'::
You should consider using 'dcommit' instead of this command.
Commit specified commit or tree objects to SVN. This relies on
@@ -256,16 +267,18 @@ config key: svn.authorsfile
Make git-svn less verbose.
--repack[=<n>]::
---repack-flags=<flags>
- These should help keep disk usage sane for large fetches
- with many revisions.
+--repack-flags=<flags>::
+
+These should help keep disk usage sane for large fetches
+with many revisions.
- --repack takes an optional argument for the number of revisions
- to fetch before repacking. This defaults to repacking every
- 1000 commits fetched if no argument is specified.
+--repack takes an optional argument for the number of revisions
+to fetch before repacking. This defaults to repacking every
+1000 commits fetched if no argument is specified.
- --repack-flags are passed directly to gitlink:git-repack[1].
+--repack-flags are passed directly to gitlink:git-repack[1].
+[verse]
config key: svn.repack
config key: svn.repackflags
@@ -323,28 +336,30 @@ CONFIG FILE-ONLY OPTIONS
svn.noMetadata::
svn-remote.<name>.noMetadata::
- This gets rid of the git-svn-id: lines at the end of every commit.
- If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
- be able to rebuild it and you won't be able to fetch again,
- either. This is fine for one-shot imports.
+This gets rid of the git-svn-id: lines at the end of every commit.
+
+If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
+be able to rebuild it and you won't be able to fetch again,
+either. This is fine for one-shot imports.
- The 'git-svn log' command will not work on repositories using
- this, either. Using this conflicts with the 'useSvmProps'
- option for (hopefully) obvious reasons.
+The 'git-svn log' command will not work on repositories using
+this, either. Using this conflicts with the 'useSvmProps'
+option for (hopefully) obvious reasons.
svn.useSvmProps::
svn-remote.<name>.useSvmProps::
- This allows git-svn to re-map repository URLs and UUIDs from
- mirrors created using SVN::Mirror (or svk) for metadata.
- If an SVN revision has a property, "svm:headrev", it is likely
- that the revision was created by SVN::Mirror (also used by SVK).
- The property contains a repository UUID and a revision. We want
- to make it look like we are mirroring the original URL, so
- introduce a helper function that returns the original identity
- URL and UUID, and use it when generating metadata in commit
- messages.
+This allows git-svn to re-map repository URLs and UUIDs from
+mirrors created using SVN::Mirror (or svk) for metadata.
+
+If an SVN revision has a property, "svm:headrev", it is likely
+that the revision was created by SVN::Mirror (also used by SVK).
+The property contains a repository UUID and a revision. We want
+to make it look like we are mirroring the original URL, so
+introduce a helper function that returns the original identity
+URL and UUID, and use it when generating metadata in commit
+messages.
svn.useSvnsyncProps::
svn-remote.<name>.useSvnsyncprops::
@@ -369,8 +384,8 @@ section because they affect the 'git-svn-id:' metadata line.
--
-Basic Examples
-~~~~~~~~~~~~~~
+BASIC EXAMPLES
+--------------
Tracking and contributing to a the trunk of a Subversion-managed project:
--
1.5.0.2.285.g5347
next prev parent reply other threads:[~2007-03-01 19:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-01 19:41 [PATCH 1/4] Documentation/build-docdep.perl: Fix dependencies for included asciidoc files Sergey Vlasov
2007-03-01 19:41 ` [PATCH 2/4] Documentation/git-quiltimport.txt: Fix labeled list formatting Sergey Vlasov
2007-03-01 19:41 ` [PATCH 3/4] Documentation/git-send-email.txt: " Sergey Vlasov
2007-03-01 19:41 ` Sergey Vlasov [this message]
2007-03-01 20:38 ` [PATCH 4/4] Documentation/git-svn.txt: Fix formatting errors Eric Wong
2007-03-02 18:23 ` Sergey Vlasov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11727781092949-git-send-email-vsu@altlinux.ru \
--to=vsu@altlinux.ru \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).