summaryrefslogtreecommitdiff
path: root/Documentation/git-svn.txt
AgeCommit message (Collapse)AuthorFilesLines
2021-09-07git-svn: drop support for `--preserve-merges`Libravatar Johannes Schindelin1-1/+0
We already passed the `--rebase-merges` option to `git rebase` instead, now we make this move permanent. As pointed out by Ævar Arnfjörð Bjarmason, in contrast to the deprecation of `git rebase`'s `--preserve-merges` backend, `git svn` only deprecated this option in v2.25.0 (because this developer missed `git svn`'s use of that backend when deprecating the rebase backend running up to Git v2.22). Still, v2.25.0 has been released on January 13th, 2020. In other words, `git svn` deprecated this option over one and a half years ago, _and_ has been redirecting to the `--rebase-merges` option during all that time (read: `git svn rebase --preserve-merges` didn't do _precisely_ what the user asked, since v2.25.0, anyway, it fell back to pretending that the user asked for `git svn rebase --rebase-merges` instead). It is time to act on that deprecation and remove that option after all. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-10docs: fix linting issues due to incorrect relative section orderLibravatar Ævar Arnfjörð Bjarmason1-19/+19
Re-order the sections of a few manual pages to be consistent with the entirety of the rest of our documentation. This allows us to remove the just-added whitelist of "bad" order from lint-man-section-order.perl. I'm doing that this way around so that code will be easy to dig up if we'll need it in the future. I've intentionally not added some other sections such as EXAMPLES to the list of known sections. If we were to add that we'd find some out of order. Perhaps we'll want to order those consistently as well in the future, at which point whitelisting some of them might become handy again. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20Documentation: stylistically normalize references to Signed-off-by:Libravatar Bradley M. Kuhn1-2/+2
Ted reported an old typo in the git-commit.txt and merge-options.txt. Namely, the phrase "Signed-off-by line" was used without either a definite nor indefinite article. Upon examination, it seems that the documentation (including items in Documentation/, but also option help strings) have been quite inconsistent on usage when referring to `Signed-off-by`. First, very few places used a definite or indefinite article with the phrase "Signed-off-by line", but that was the initial typo that led to this investigation. So, normalize using either an indefinite or definite article consistently. The original phrasing, in Commit 3f971fc425b (Documentation updates, 2005-08-14), is "Add Signed-off-by line". Commit 6f855371a53 (Add --signoff, --check, and long option-names. 2005-12-09) switched to using "Add `Signed-off-by:` line", but didn't normalize the former commit to match. Later commits seem to have cut and pasted from one or the other, which is likely how the usage became so inconsistent. Junio stated on the git mailing list in <xmqqy2k1dfoh.fsf@gitster.c.googlers.com> a preference to leave off the colon. Thus, prefer `Signed-off-by` (with backticks) for the documentation files and Signed-off-by (without backticks) for option help strings. Additionally, Junio argued that "trailer" is now the standard term to refer to `Signed-off-by`, saying that "becomes plenty clear that we are not talking about any random line in the log message". As such, prefer "trailer" over "line" anywhere the former word fits. However, leave alone those few places in documentation that use Signed-off-by to refer to the process (rather than the specific trailer), or in places where mail headers are generally discussed in comparison with Signed-off-by. Reported-by: "Theodore Y. Ts'o" <tytso@mit.edu> Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org> Acked-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-23git svn: stop using `rebase --preserve-merges`Libravatar Johannes Schindelin1-1/+2
We deprecated `--preserve-merges` in favor of `--rebase-merges`; Let's reflect that in `git svn`. Note: Even when the user asks for `--preserve-merges`, we now silently pass `--rebase-merges` to `git rebase` instead. Technically, this is a change of behavior. But practically, `git svn` only ever asks for a non-interactive rebase, and `--preserve-merges` and `--rebase-merges` are on par with regard to that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05Recommend git-filter-repo instead of git-filter-branchLibravatar Elijah Newren1-5/+5
filter-branch suffers from a deluge of disguised dangers that disfigure history rewrites (i.e. deviate from the deliberate changes). Many of these problems are unobtrusive and can easily go undiscovered until the new repository is in use. This can result in problems ranging from an even messier history than what led folks to filter-branch in the first place, to data loss or corruption. These issues cannot be backward compatibly fixed, so add a warning to both filter-branch and its manpage recommending that another tool (such as filter-repo) be used instead. Also, update other manpages that referenced filter-branch. Several of these needed updates even if we could continue recommending filter-branch, either due to implying that something was unique to filter-branch when it applied more generally to all history rewriting tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because something about filter-branch was used as an example despite other more commonly known examples now existing. Reword these sections to fix these issues and to avoid recommending filter-branch. Finally, remove the section explaining BFG Repo Cleaner as an alternative to filter-branch. I feel somewhat bad about this, especially since I feel like I learned so much from BFG that I put to good use in filter-repo (which is much more than I can say for filter-branch), but keeping that section presented a few problems: * In order to recommend that people quit using filter-branch, we need to provide them a recomendation for something else to use that can handle all the same types of rewrites. To my knowledge, filter-repo is the only such tool. So it needs to be mentioned. * I don't want to give conflicting recommendations to users * If we recommend two tools, we shouldn't expect users to learn both and pick which one to use; we should explain which problems one can solve that the other can't or when one is much faster than the other. * BFG and filter-repo have similar performance * All filtering types that BFG can do, filter-repo can also do. In fact, filter-repo comes with a reimplementation of BFG named bfg-ish which provides the same user-interface as BFG but with several bugfixes and new features that are hard to implement in BFG due to its technical underpinnings. While I could still mention both tools, it seems like I would need to provide some kind of comparison and I would ultimately just say that filter-repo can do everything BFG can, so ultimately it seems that it is just better to remove that section altogether. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-09Merge branch 'tz/git-svn-doc-markup-fix'Libravatar Junio C Hamano1-3/+3
Doc formatting fix. * tz/git-svn-doc-markup-fix: Documentation/git-svn: improve asciidoctor compatibility
2019-04-10Documentation/git-svn: improve asciidoctor compatibilityLibravatar Todd Zullinger1-3/+3
The second paragraph in the CONFIGURATION section intends to emphasize the word 'must' with bold type. It does so by writing it as *must*, and this works fine with AsciiDoc. It usually works great with Asciidoctor, too, but in this particular instance, we have another "*" earlier in the paragraph. We do escape it, and it is rendered literally just like we want it to, but Asciidoctor then ends up tripping on the second (or third) of the asterisks in this paragraph. Since that asterisk is (part of) a literal example, we can set it in monospace, by giving it as `*`. Adjust the whole paragraph in this way. There's lots more monospacing to be done in this document, but since our main motivation is addressing AsciiDoc/Asciidoctor discrepancies like this one, let's just convert this one paragraph. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07git-svn.txt: drop escaping '\' that ends up being renderedLibravatar Martin Ågren1-5/+5
Escaping two *'s as "\*\*" apparently makes Asciidoctor render the second backslash literally, so we end up with "*\*". So let's not escape that second asterisk. The result is now "**" as intended, both in AsciiDoc and Asciidoctor. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-22Documentation: spelling and grammar fixesLibravatar Ville Skyttä1-1/+1
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-25Use proper syntax for replaceables in command docsLibravatar Robert P. J. Day1-1/+1
The standard for command documentation synopses appears to be: [...] means optional <...> means replaceable [<...>] means both optional and replaceable So fix a number of doc pages that use incorrect variations of the above. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-23Merge branch 'ah/misc-doc-updates'Libravatar Junio C Hamano1-1/+1
Misc doc fixes. * ah/misc-doc-updates: doc: normalize [--options] to [options] in git-diff doc: add note about shell quoting to revision.txt git-svn: remove ''--add-author-from' for 'commit-diff' doc: add '-d' and '-o' for 'git push' doc: clarify ignore rules for git ls-files doc: align 'diff --no-index' in text and synopsis doc: improve formatting in githooks.txt
2018-05-06git-svn: remove ''--add-author-from' for 'commit-diff'Libravatar Andreas Heiduk1-1/+1
The subcommand 'commit-diff' does not support the option '--add-author-from'. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05git-svn: allow empty email-address using authors-prog and authors-fileLibravatar Andreas Heiduk1-3/+5
The email address in --authors-file and --authors-prog can be empty but git-svn translated it into a fictional email address in the form jondoe <jondoe@6aafaa21e0fb4338a68ab372a049893d> containing the SVN repository UUID. Now git-svn behaves like git-commit: If the email is *explicitly* set to the empty string using '<>', the commit does not contain an email address, only the name: jondoe <> Allowing to remove the email address *intentionally* prevents automatic systems from sending emails to those fictional addresses and avoids cluttering the log output with unnecessary stuff. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Eric Wong <e@80x24.org>
2018-04-05git-svn: search --authors-prog in PATH tooLibravatar Andreas Heiduk1-0/+5
In 36db1eddf9 ("git-svn: add --authors-prog option", 2009-05-14) the path to authors-prog was made absolute because git-svn changes the current directory in some situations. This makes sense if the program is part of the repository but prevents searching via $PATH. The old behaviour is still retained, but if the file does not exists, then authors-prog is searched for in $PATH as any other command. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Eric Wong <e@80x24.org>
2017-08-23treewide: correct several "up-to-date" to "up to date"Libravatar Martin Ågren1-1/+1
Follow the Oxford style, which says to use "up-to-date" before the noun, but "up to date" after it. Don't change plumbing (specifically send-pack.c, but transport.c (git push) also has the same string). This was produced by grepping for "up-to-date" and "up to date". It turned out we only had to edit in one direction, removing the hyphens. Fix a typo in Documentation/git-diff-index.txt while we're there. Reported-by: Jeffrey Manian <jeffrey.manian@gmail.com> Reported-by: STEVEN WHITE <stevencharleswhitevoices@gmail.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15git-svn: document special options for commit-diffLibravatar Andreas Heiduk1-0/+15
Some options specific for `git svn commit-diff` where not documented so far. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Eric Wong <e@80x24.org>
2017-06-07doc: describe git svn init --ignore-refsLibravatar Andreas Heiduk1-0/+16
Add the missing documentation for `git svn init --ignore-refs`. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Eric Wong <e@80x24.org>
2016-12-12git-svn: document useLogAuthor and addAuthorFrom config keysLibravatar Eric Wong1-1/+7
We've always supported these config keys in git-svn, so document them so users won't have to respecify them on every invocation. Reported-by: Juergen Kosel <juergen.kosel@gmx.de> Signed-off-by: Eric Wong <e@80x24.org>
2016-07-19git-svn: document svn.authorsProg in configLibravatar Eric Wong1-0/+3
This has always been supported since we read config variables based on the command-line option parser. Document it explicitly since users usually want to maintain the same program across invocations. Signed-off-by: Eric Wong <e@80x24.org>
2016-07-13Merge branch 'mm/doc-tt'Libravatar Junio C Hamano1-13/+13
More mark-up updates to typeset strings that are expected to literally typed by the end user in fixed-width font. * mm/doc-tt: doc: typeset HEAD and variants as literal CodingGuidelines: formatting HEAD in documentation doc: typeset long options with argument as literal doc: typeset '--' as literal doc: typeset long command-line options as literal doc: typeset short command-line options as literal Documentation/git-mv.txt: fix whitespace indentation
2016-06-28doc: typeset long command-line options as literalLibravatar Matthieu Moy1-13/+13
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-27Merge branch 'ap/git-svn-propset-doc'Libravatar Junio C Hamano1-0/+14
"git svn propset" subcommand that was added in 2.3 days is documented now. * ap/git-svn-propset-doc: git-svn: document the 'git svn propset' command
2016-06-15git-svn: document the 'git svn propset' commandLibravatar Alfred Perlstein1-0/+14
Add example usage to the git-svn documentation. Reported-by: Joseph Pecoraro <pecoraro@apple.com> Signed-off-by: Alfred Perlstein <alfred@freebsd.org> Reviewed-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-08doc: change configuration variables formatLibravatar Tom Russello1-1/+1
This change configuration variables that where in italic style to monospace font according to the guideline. It was obtained with grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \ sed -e 's/::$//' -e 's/\./\\\\./' | \ xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-15git-svn: loosen config globs limitationsLibravatar Victor Leschuk1-0/+12
Expand the area of globs applicability for branches and tags in git-svn. It is now possible to use globs like 'a*e', or 'release_*'. This allows users to avoid long lines in config like: branches = branches/{release_20,release_21,release_22,...} In favor of: branches = branches/release_* [ew: amended commit message, minor formatting and style fixes] Signed-off-by: Victor Leschuk <vleschuk@accesssoftek.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2015-09-01Merge branch 'br/svn-doc-include-paths-config'Libravatar Junio C Hamano1-0/+3
* br/svn-doc-include-paths-config: git-svn doc: mention "svn-remote.<name>.include-paths"
2015-08-26git-svn doc: mention "svn-remote.<name>.include-paths"Libravatar Brett Randall1-0/+3
Mention the configuration variable in a way similar to how "svn-remote.<name>.ignore-paths" is mentioned. Signed-off-by: Brett Randall <javabrett@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-12doc: put example URLs and emails inside literal backticksLibravatar Jeff King1-2/+2
This makes sure that AsciiDoc does not turn them into links. Regular AsciiDoc does not catch these cases, but AsciiDoctor does treat them as links. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-12doc: fix hanging "+"-continuationLibravatar Jeff King1-3/+3
In list content that wants to continue to a second paragraph, the "+" continuation and subsequent paragraph need to be left-aligned. Otherwise AsciiDoc seems to insert only a linebreak. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-04Documentation: typofixesLibravatar Thomas Ackermann1-2/+2
In addition to fixing trivial and obvious typos, be careful about the following points: - Spell ASCII, URL and CRC in ALL CAPS; - Spell Linux as Capitalized; - Do not omit periods in "i.e." and "e.g.". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-24git-svn.txt: advertise pushurl with dcommitLibravatar Sveinung Kvilhaugsvik1-0/+4
Advertise that the svn-remote.<name>.pushurl config key allows specifying the commit URL for the entire SVN repository in the documentation of the git svn dcommit command. Signed-off-by: Sveinung Kvilhaugsvik <sveinung84@users.sourceforge.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2014-09-14git svn: find-rev allows short switches for near matchesLibravatar Eric Wong1-0/+2
Allow -B and -A to act as short aliases for --before and --after options respectively. This reduces typing and hopefully allows reuse of muscle memory for grep(1) users. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2014-09-14git-svn.txt: Remove mentions of repack optionsLibravatar Lawrence Velázquez1-15/+0
Git no longer seems to use these flags or their associated config keys; when they are present, git-svn outputs a message indicating that they are being ignored. Signed-off-by: Lawrence Velázquez <vq@larryv.me> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2014-05-21Documentation: use "command-line" when used as a compound adjective, and fix ↵Libravatar Jason St. John1-2/+2
other minor grammatical issues Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-23t9117: use --prefix "" instead of --prefix=""Libravatar Kyle J. McKay1-0/+3
Versions of Perl's Getopt::Long module before 2.37 do not contain this fix that first appeared in Getopt::Long version 2.37: * Bugfix: With gnu_compat, --foo= will no longer trigger "Option requires an argument" but return the empty string. Instead of using --prefix="" use --prefix "" when testing an explictly empty prefix string in order to work with older versions of Perl's Getopt::Long module. Also add a paragraph on this workaround to the documentation of git-svn itself. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-19Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not givenLibravatar Johan Herland1-16/+4
git-svn by default puts its Subversion-tracking refs directly in refs/remotes/*. This runs counter to Git's convention of using refs/remotes/$remote/* for storing remote-tracking branches. Furthermore, combining git-svn with regular git remotes run the risk of clobbering refs under refs/remotes (e.g. if you have a git remote called "tags" with a "v1" branch, it will overlap with the git-svn's tracking branch for the "v1" tag from Subversion. Even though the git-svn refs stored in refs/remotes/* are not "proper" remote-tracking branches (since they are not covered by a proper git remote's refspec), they clearly represent a similar concept, and would benefit from following the same convention. For example, if git-svn tracks Subversion branch "foo" at refs/remotes/foo, and you create a local branch refs/heads/foo to add some commits to be pushed back to Subversion (using "git svn dcommit), then it is clearly unhelpful of Git to throw warning: refname 'foo' is ambiguous. every time you checkout, rebase, or otherwise interact with the branch. The existing workaround for this is to supply the --prefix=quux/ to git svn init/clone, so that git-svn's tracking branches end up in refs/remotes/quux/* instead of refs/remotes/*. However, encouraging users to specify --prefix to work around a design flaw in git-svn is suboptimal, and not a long term solution to the problem. Instead, git-svn should default to use a non-empty prefix that saves unsuspecting users from the inconveniences described above. This patch will only affect newly created git-svn setups, as the --prefix option only applies to git svn init (and git svn clone). Existing git-svn setups will continue with their existing (lack of) prefix. Also, if anyone somehow prefers git-svn's old layout, they can recreate that by explicitly passing an empty prefix (--prefix "") on the git svn init/clone command line. The patch changes the default value for --prefix from "" to "origin/", updates the git-svn manual page, and fixes the fallout in the git-svn testcases. (Note that this patch might be easier to review using the --word-diff and --word-diff-regex=. diff options.) [ew: squashed description of <= 1.9 behavior into manpage] Suggested-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-11-12Correct word usage of "timezone" in "Documentation" directoryLibravatar Jason St. John1-3/+3
"timezone" is two words, not one (i.e. "time zone" is correct). Correct this in these files: -- date-formats.txt -- git-blame.txt -- git-cvsimport.txt -- git-fast-import.txt -- git-svn.txt -- gitweb.conf.txt -- rev-list-options.txt Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30Merge branch 'sb/git-svn-docs-indent-with-ht'Libravatar Junio C Hamano1-13/+13
* sb/git-svn-docs-indent-with-ht: git-svn docs: Use tabs consistently within the ascii doc
2013-10-22git-svn docs: Use tabs consistently within the ascii docLibravatar Stefan Beller1-13/+13
While I can understand 4 or 7 white spaces are fancy, we'd rather want to use tabs throughout the whole document. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-12git-svn: Warn about changing default for --prefix in Git v2.0Libravatar Johan Herland1-1/+10
In Git v2.0, we will change the default --prefix for init/clone from none/empty to "origin/" (which causes SVN-tracking branches to be placed at refs/remotes/origin/* instead of refs/remotes/*). This patch warns users about the upcoming change, both in the git-svn manual page, and on stderr when running init/clone in the "multi-mode" without providing a --prefix. Cc: Eric Wong <normalperson@yhbt.net> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-12Documentation/git-svn: Promote the use of --prefix in docs + examplesLibravatar Johan Herland1-10/+25
Currently, the git-svn defaults to using an empty prefix, which ends up placing the SVN-tracking refs directly in refs/remotes/*. This placement runs counter to Git's convention of placing remote-tracking branches in refs/remotes/$remote/*. Furthermore, combining git-svn with "regular" Git remotes run the risk of clobbering refs under refs/remotes (e.g. if you have a git remote called "tags" with a "v1" branch, it will overlap with the git-svn's tracking branch for the "v1" tag from Subversion. Even though the git-svn refs stored in refs/remotes/* are not "proper" remote-tracking branches (since they are not covered by a proper git remote's refspec), they clearly represent a similar concept, and would benefit from following the same convention. For example, if git-svn tracks Subversion branch "foo" at refs/remotes/foo, and you create a local branch refs/heads/foo to add some commits to be pushed back to Subversion (using "git svn dcommit), then it is clearly unhelpful of Git to throw warning: refname 'foo' is ambiguous. every time you checkout, rebase, or otherwise interact with the branch. At this time, the user is better off using the --prefix=foo/ (the trailing slash is important) to git svn init/clone, to cause the SVN-tracking refs to be placed at refs/remotes/foo/* instead of refs/remotes/*. This patch updates the documentation to encourage use of --prefix. This is also in preparation for changing the default value of --prefix at some point in the future. Cc: Eric Wong <normalperson@yhbt.net> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-10git-svn.txt: elaborate on rev_map filesLibravatar Keshav Kini1-4/+24
The man page for `git svn` describes a situation in which "'git svn' will not be able to rebuild" your $GIT_DIR/svn/**/.rev_map* files, but no mention is made of in what circumstances `git svn` *will* be able to do so, how to get `git svn` to do so, or even what these files are. This patch adds a FILES section to the man page with a description of what $GIT_DIR/svn/**/.rev_map* files are and how they are (re)built, and links to this description from various other parts of the man page. Signed-off-by: Keshav Kini <keshav.kini@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-10git-svn.txt: replace .git with $GIT_DIRLibravatar Keshav Kini1-8/+8
As $GIT_DIR may not equal '.git', it's usually more generally correct to refer to files in $GIT_DIR rather than in .git . This will also allow me to link some of the occurrences of '.git' in git-svn.txt to a new reference target inside this file in an upcoming commit, because in AsciiDoc definitions apparently can't start with a '.' character. Signed-off-by: Keshav Kini <keshav.kini@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-10git-svn.txt: reword description of gc commandLibravatar Keshav Kini1-2/+2
It's redundant to say that $GIT_DIR/svn/<refname>/unhandled.log or $GIT_DIR/svn/<refname>/index is in .git/svn when $GIT_DIR is '.git', and is wrong when $GIT_DIR is not '.git' Also, a '/' was missing from the pathname $GIT_DIR/svn/<refname>/index . Signed-off-by: Keshav Kini <keshav.kini@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-10git-svn.txt: fix AsciiDoc formatting errorLibravatar Keshav Kini1-1/+1
As asterisks are used to indicate bold text in AsciiDoc, shell glob expressions must be escaped appropriately. Signed-off-by: Keshav Kini <keshav.kini@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-08-05fix typo in documentation of git-svnLibravatar Felix Gruber1-1/+1
Signed-off-by: Felix Gruber <felgru@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20git-svn: introduce --parents parameter for commands branch and tagLibravatar Tobias Schulte1-0/+5
This parameter is equivalent to the parameter --parents on svn cp commands and is useful for non-standard repository layouts. Signed-off-by: Tobias Schulte <tobias.schulte@gliderpilot.de> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-05-20git-svn: clarify explanation of --destination argumentLibravatar Jonathan Nieder1-5/+14
The existing documentation for "-d" does not make it obvious whether its argument is supposed to be a full svn path, a partial svn path, the glob from the config file, or what. Clarify the text and add an example to get the reader started. Reported-by: Nathan Gray <n8gray@n8gray.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-05-20git-svn: multiple fetch/branches/tags keys are supportedLibravatar Nathan Gray1-0/+12
"git svn" can be configured to use multiple fetch, branches, and tags refspecs by passing multiple --branches or --tags options at init time or editing the configuration file later, which can be handy when working with messy Subversion repositories. Add a note to the configuration section documenting how this works. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-05-09git-svn: added an --include-path flagLibravatar Paul Walmsley1-0/+12
The SVN::Fetcher module is now able to filter for inclusion as well as exclusion (as used by --ignore-path). Also added tests, documentation changes and git completion script. If you have an SVN repository with many top level directories and you only want a git-svn clone of some of them then using --ignore-path is difficult as it requires a very long regexp. In this case it's much easier to filter for inclusion. [ew: remove trailing whitespace] Signed-off-by: Paul Walmsley <pjwhams@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>