Re: [PATCH] git-svn.txt: mention how to rebuild rev_map files

From: Keshav Kini <keshav.kini@gmail.com>
Date: Sep 25, 2013, 23:37 UTC
Message-ID: <874n98qxqx.fsf@gmail.com>
In-Reply-To: <20130925194402.GA9464@google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 28 quoted lines

> Taking a step back, the reader might wonder *why* he would want
> to run "git svn fetch" to rebuilt these .rev_map.* files, and what
> they are for.
>
> Perhaps there should be a separate REVISION MAP section describing
> this in more detail.  Something as simple as
>
> 	FILES
> 	-----
> 	.git/svn/\*\*/.rev_map.\*::
> 		Mapping between Subversion revision numbers and Git
> 		commit names.  Can be rebuilt using the git-svn-id:
> 		lines at the end of every commit as long as the
> 		noMetadata option is not set (see the 'svn.noMetadata'
> 		section above for details).
> 	+
> 	'git svn fetch' and 'git svn rebase' automatically update
> 	the rev_map if it is missing or not up to date.  'git svn
> 	reset' automatically rewinds it.
>
> Then this reference in 'fetch' could just say something like
>
> 	...
> 	argument.
> 	+
>  This automatically updates the rev_map if needed (see
>  '.git/svn/\*\*/.rev_map.\*' in the FILES section below for
>  details).

Note that only the first two asterisks are escaped in my patch. For some reason, escaping all three causes a literal '\' to appear in asciidoc's output...

I changed the wording of your first paragraph a bit according to what I thought it meant. Does it still convey what you wanted to convey, and is it still correct?

	Mapping between Subversion revision numbers and Git commit
	names.  In a repository where the noMetadata option is not set,
	this can be rebuilt from the git-svn-id: lines that are at the
	end of every commit (see the 'svn.noMetadata' section above for
	details).

Also, I'm having a bit of trouble trying to get a definition to start with a '.' character in AsciiDoc. Escaping the '.' produces a definition block, but with a literal '\' before the '.'. If I don't escape the '.', asciidoc thinks it's a section heading or something. Is asciidoc just incapable of doing this, or am I missing something?

-Keshav