svn

NAME名

git-svn - Bidirectional operation between a Subversion repository and Gitgit-svn - SubversionリポジトリとGitの間の双方向操作

SYNOPSIS概要

git svn <command> [<options>] [<arguments>]

DESCRIPTION説明

git svn is a simple conduit for changesets between Subversion and Git. It provides a bidirectional flow of changes between a Subversion and a Git repository.git svnはSubversionとGitの間のチェンジセットのための単純なコンジットです。SubversionとGitリポジトリ間で双方向の変更の流れを提供します。

git svn can track a standard Subversion repository, following the common "trunk/branches/tags" layout, with the --stdlayout option. It can also follow branches and tags in any layout with the -T/-t/-b options (see options to init below, and also the clone command).git svnは標準のSubversionリポジトリを追跡することができ、共通の "trunk / branches / tags"のレイアウトに従って--stdlayoutオプションを付けます。また、-T / -t / -bオプションを使用して、任意のレイアウトのブランチやタグを追跡することもできます（以下のinitのオプション、およびcloneコマンドも参照）。

Once tracking a Subversion repository (with any of the above methods), the Git repository can be updated from Subversion by the fetch command and Subversion updated from Git by the dcommit command.Subversionリポジトリを（上記のいずれかの方法で）追跡すると、GitリポジトリはSubversionからfetchコマンドで、SubversionはGitからdcommitコマンドで更新できます。

COMMANDSコマンド

init その中に

Initializes an empty Git repository with additional metadata directories for git svn. The Subversion URL may be specified as a command-line argument, or as full URL arguments to -T/-t/-b. Optionally, the target directory to operate on can be specified as a second argument. Normally this command initializes the current directory.git svn用の追加のメタデータディレクトリで空のGitリポジトリを初期化します。SubversionのURLは、コマンドライン引数として指定することも、-T / -t / -bへの完全URL引数として指定することもできます。オプションで、操作対象のターゲットディレクトリを2番目の引数として指定できます。通常このコマンドはカレントディレクトリを初期化します。

-T<trunk_subdir> -T <トランクサブディレクトリ>
--trunk=<trunk_subdir> --trunk = <trunk_subdir>
-t<tags_subdir> -t <tags_subdir>
--tags=<tags_subdir> --tags = <tags_subdir>
-b<branches_subdir> -b <branches_subdir>
--branches=<branches_subdir> --branches = <branches_subdir>
-s
--stdlayout

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). You can specify more than one --tags and/or --branches options, in case your Subversion repository places tags or branches under multiple paths. The option --stdlayout is a shorthand way of setting trunk,tags,branches as the relative paths, which is the Subversion default. If any of the other options are given as well, they take precedence.これらはinitのオプションのコマンドラインオプションです。これらの各フラグは、相対リポジトリパス（--tags = project / tags）またはフルURL（--tags = https：//foo.org/project/tags）を指すことができます。Subversionリポジトリがタグやブランチを複数のパスの下に置く場合に備えて、複数の--tagsや--branchesオプションを指定することができます。オプション--stdlayoutはトランク、タグ、ブランチを相対パスとして設定するための簡単な方法です。これはSubversionのデフォルトです。他のオプションも指定されている場合は、それらが優先されます。

--no-metadata

Set the noMetadata option in the [svn-remote] config. This option is not recommended, please read the svn.noMetadata section of this manpage before using this option.設定しnoMetadataの [SVN-リモート]設定でオプションを選択します。このオプションはお勧めできません。このオプションを使用する前に、このマンページのsvn.noMetadataセクションを読んでください。

--use-svm-props

Set the useSvmProps option in the [svn-remote] config.設定しuseSvmPropsの [SVN-リモート]設定でオプションを選択します。

--use-svnsync-props

Set the useSvnsyncProps option in the [svn-remote] config.設定しuseSvnsyncPropsの [SVN-リモート]設定でオプションを選択します。

--rewrite-root=<URL> --rewrite-root = <URL>

Set the rewriteRoot option in the [svn-remote] config.[svn-remote]設定でrewriteRootオプションを設定してください。

--rewrite-uuid=<UUID> --rewrite-uuid = <UUID>

Set the rewriteUUID option in the [svn-remote] config.[svn-remote]設定でrewriteUUIDオプションを設定してください。

--username=<user> --username = <ユーザー>

For transports that SVN handles authentication for (http, https, and plain svn), specify the username. For other transports (e.g. svn+ssh://), you must include the username in the URL, e.g. svn+ssh://foo@svn.bar.com/projectSVNが（http、https、およびplain svn）の認証を処理するトランスポートの場合は、ユーザー名を指定します。他のトランスポート（例svn+ssh://）の場合は、URLにユーザー名を含める必要があります。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 trailing slash, so be sure you include one in the argument if that is what you want. If --branches/-b is specified, the prefix must include a trailing slash. Setting a prefix (with a trailing slash) is strongly encouraged in any case, as your SVN-tracking refs will then be located at "refs/remotes/$prefix/", which is compatible with Git’s own remote-tracking ref layout (refs/remotes/$remote/). Setting a prefix is also useful if you wish to track multiple projects that share a common repository. By default, the prefix is set to origin/.これは、trunk / branches / tagsが指定されている場合、リモートの名前の前に付加される接頭辞を指定することを可能にします。接頭辞は自動的に末尾のスラッシュを含みませんので、それがあなたが望むものであるなら、引数に必ずそれを含めるようにしてください。--branches / -bが指定されている場合、接頭辞に末尾のスラッシュを含める必要があります。どのような場合でも接頭辞（末尾のスラッシュ付き）を設定することを強くお勧めします。SVN追跡参照はGit独自のリモート追跡参照レイアウト（refs）と互換性のある "refs / remotes / $ prefix / "に配置されるためです。 / remotes / $ remote /）共通のリポジトリを共有する複数のプロジェクトを追跡したい場合は、プレフィックスを設定することも便利です。デフォルトでは、プレフィックスはorigin /に設定されています。

Note Before Git v2.0, the default prefix was "" (no prefix). This meant that SVN-tracking refs were put at "refs/remotes/*", which is incompatible with how Git’s own remote-tracking refs are organized. If you still want the old default, you can get it by passing --prefix "" on the command line (--prefix="" may not work if your Perl’s Getopt::Long is < v2.37). Git v2.0より前では、デフォルトのプレフィックスは ""（プレフィックスなし）でした。これは、SVN追跡参照が "refs / remotes / *"に置かれたことを意味していました。これはGit自身のリモート追跡参照がどのように編成されているかとは両立しません。それでも古いデフォルトを使用したい場合--prefix ""は、コマンドラインを渡して取得でき--prefix=""ます（PerlのGetopt :: Longが<v2.37の場合は機能しない可能性があります）。
--ignore-refs=<regex> --ignore-refs = <正規表現>

When passed to init or clone this regular expression will be preserved as a config key. See fetch for a description of --ignore-refs.initまたはcloneに渡されると、この正規表現は設定キーとして保存されます。の説明についてはfetchを参照してください--ignore-refs。

--ignore-paths=<regex> --ignore-paths = <正規表現>

When passed to init or clone this regular expression will be preserved as a config key. See fetch for a description of --ignore-paths.initまたはcloneに渡されると、この正規表現は設定キーとして保存されます。の説明についてはfetchを参照してください--ignore-paths。

--include-paths=<regex> --include-paths = <正規表現>

When passed to init or clone this regular expression will be preserved as a config key. See fetch for a description of --include-paths.initまたはcloneに渡されると、この正規表現は設定キーとして保存されます。の説明についてはfetchを参照してください--include-paths。

--no-minimize-url --no-optimize-url

When tracking multiple directories (using --stdlayout, --branches, or --tags options), git svn will attempt to connect to the root (or highest allowed level) of the Subversion repository. This default allows better tracking of history if entire projects are moved within a repository, but may cause issues on repositories where read access restrictions are in place. Passing --no-minimize-url will allow git svn to accept URLs as-is without attempting to connect to a higher level directory. This option is off by default when only one URL/branch is tracked (it would do little good).複数のディレクトリを追跡するとき（--stdlayout、 - branch、または--tagsオプションを使用）、git svnはSubversionリポジトリのルート（または最高許容レベル）への接続を試みます。プロジェクト全体をリポジトリ内で移動した場合、このデフォルトで履歴の追跡が向上しますが、読み取りアクセス制限が設定されているリポジトリでは問題が発生する可能性があります。渡す--no-minimize-urlことで、git svnはより高いレベルのディレクトリに接続しようとせずにURLをそのまま受け入れることができます。1つのURL /ブランチしか追跡されていない場合、このオプションはデフォルトでオフになっています（ほとんど効果がありません）。

fetch フェッチ

Fetch unfetched revisions from the Subversion remote we are tracking. The name of the [svn-remote "…​"] section in the $GIT_DIR/config file may be specified as an optional command-line argument.追跡しているSubversionリモートから未取得のリビジョンを取得します。$ GIT_DIR / configファイルの[svn-remote "…"]セクションの名前は、オプションのコマンドライン引数として指定できます。

This automatically updates the rev_map if needed (see $GIT_DIR/svn/*\*/.rev_map.* in the FILES section below for details).必要ならば、これはrev_mapを自動的に更新します（詳細については、下記のファイルセクションの$ GIT_DIR / svn / * \ * /。rev_map。*を参照してください）。

--localtime - 現地時間

Store Git commit times in the local time zone instead of UTC. This makes git log (even without --date=local) show the same times that svn log would in the local time zone.Gitのコミット時刻をUTCではなく現地のタイムゾーンで保存します。これによりgit logは（--date = localがなくても）svn logローカルタイムゾーンと同じ時間を表示します。

This doesn’t interfere with interoperating with the Subversion repository you cloned from, but if you wish for your local Git repository to be able to interoperate with someone else’s local Git repository, either don’t use this option or you should both use it in the same local time zone.これはあなたがクローンしたSubversionリポジトリとの相互運用を妨げるものではありませんが、もしあなたのローカルGitリポジトリが他の誰かのローカルGitリポジトリと相互運用できるようにしたいのなら、このオプションを使わないか両方で使うべきです。同じ現地時間帯。

--parent - 親

Fetch only from the SVN parent of the current HEAD.現在のHEADの親SVNからのみ取得します。

--ignore-refs=<regex> --ignore-refs = <正規表現>

Ignore refs for branches or tags matching the Perl regular expression. A "negative look-ahead assertion" like ^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$ can be used to allow only certain refs.Perlの正規表現に一致するブランチやタグの参照を無視します。「否定的な先読みアサーション」のようなもの^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$は、特定の参照だけを許可するために使用できます。

config key: svn-remote.<name>.ignore-refs

If the ignore-refs configuration key is set, and the command-line option is also given, both regular expressions will be used.ignore-refs設定キーが設定されていて、コマンドラインオプションも指定されている場合は、両方の正規表現が使用されます。

--ignore-paths=<regex> --ignore-paths = <正規表現>

This allows one to specify a Perl regular expression that will cause skipping of all matching paths from checkout from SVN. The --ignore-paths option should match for every fetch (including automatic fetches due to clone, dcommit, rebase, etc) on a given repository.これにより、SVNからのチェックアウトから一致するすべてのパスをスキップするPerl正規表現を指定できます。この--ignore-pathsオプションは、指定されたリポジトリ上のすべてのフェッチ（クローン、dcommit、rebaseなどによる自動フェッチを含む）に対して一致する必要があります。

config key: svn-remote.<name>.ignore-paths

If the ignore-paths configuration key is set, and the command-line option is also given, both regular expressions will be used.ignore-paths設定キーが設定されていて、コマンドラインオプションも指定されている場合は、両方の正規表現が使用されます。

Examples:例：

Skip "doc*" directory for every fetch 取得ごとに "doc *"ディレクトリをスキップする
--ignore-paths="^doc"
Skip "branches" and "tags" of first level directories 第1レベルディレクトリの "枝"と "タグ"をスキップする
--ignore-paths="^[^/]+/(?:branches|tags)"
--include-paths=<regex> --include-paths = <正規表現>

This allows one to specify a Perl regular expression that will cause the inclusion of only matching paths from checkout from SVN. The --include-paths option should match for every fetch (including automatic fetches due to clone, dcommit, rebase, etc) on a given repository. --ignore-paths takes precedence over --include-paths.これにより、SVNからのチェックアウトから一致するパスのみを含めるようにするPerl正規表現を指定できます。この--include-pathsオプションは、指定されたリポジトリ上のすべてのフェッチ（クローン、dcommit、rebaseなどによる自動フェッチを含む）に対して一致する必要があります。--ignore-paths優先し--include-pathsます。

config key: svn-remote.<name>.include-paths
--log-window-size=<n> --log-window-size = <n>

Fetch <n> log entries per request when scanning Subversion history. The default is 100. For very large Subversion repositories, larger values may be needed for clone/fetch to complete in reasonable time. But overly large values may lead to higher memory usage and request timeouts.Subversionの履歴をスキャンするときに、リクエストごとに<n>個のログエントリを取得します。デフォルトは100です。非常に大きなSubversionリポジトリでは、クローン / フェッチを妥当な時間内に完了させるために、より大きな値が必要になるかもしれません。ただし、値が大きすぎると、メモリ使用量が増え、タイムアウトが発生する可能性があります。

clone クローン

Runs init and fetch. It will automatically create a directory based on the basename of the URL passed to it; or if a second argument is passed; it will create a directory and work within that. It accepts all arguments that the init and fetch commands accept; with the exception of --fetch-all and --parent. After a repository is cloned, the fetch command will be able to update revisions without affecting the working tree; and the rebase command will be able to update the working tree with the latest changes.initとfetchを実行します。渡されたURLのベース名に基づいてディレクトリを自動的に作成します。または2番目の引数が渡された場合 それはディレクトリを作成し、その中で動作します。initコマンドとfetchコマンドが受け入れるすべての引数を受け入れます。とを除い--fetch-allて--parent。リポジトリがクローンされた後、fetchコマンドは作業ツリーに影響を与えずにリビジョンを更新することができます。そしてrebaseコマンドは作業ツリーを最新の変更で更新することができます。

--preserve-empty-dirs

Create a placeholder file in the local Git repository for each empty directory fetched from Subversion. This includes directories that become empty by removing all entries in the Subversion repository (but not the directory itself). The placeholder files are also tracked and removed when no longer necessary.Subversionから取得した空のディレクトリごとに、ローカルのGitリポジトリにプレースホルダファイルを作成します。これには、Subversionリポジトリ内のすべてのエントリを削除することによって空になったディレクトリも含まれます（ただし、ディレクトリ自体は含まれません）。プレースホルダファイルも追跡され、不要になると削除されます。

--placeholder-filename=<filename> --placeholder-filename = <ファイル名>

Set the name of placeholder files created by --preserve-empty-dirs. Default: ".gitignore"--preserve-empty-dirsによって作成されたプレースホルダファイルの名前を設定します。デフォルト： ".gitignore"

rebase リベース

This fetches revisions from the SVN parent of the current HEAD and rebases the current (uncommitted to SVN) work against it.これは現在のHEADの親SVNからリビジョンを取得し、それに対して現在の（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 dcommitting with git svn.これは、git svnでのdcommittingを容易にするためにgit mergeの代わりにgit rebaseで線形履歴を保存することを除いて、svn updateまたはgit pullと同様に機能します。

This accepts all options that git svn fetch and git rebase accept. However, --fetch-all only fetches from the current [svn-remote], and not all [svn-remote] definitions.これはgit svn fetchとgit rebaseが受け入れるすべてのオプションを受け付けます。ただし、--fetch-all現在の[svn-remote]からのみ取得し、すべての[svn-remote]の定義からは取得しません。

Like git rebase; this requires that the working tree be clean and have no uncommitted changes.同様のgitリベース。これには、作業ツリーがきれいでコミットされていない変更がないことが必要です。

This automatically updates the rev_map if needed (see $GIT_DIR/svn/*\*/.rev_map.* in the FILES section below for details).必要ならば、これはrev_mapを自動的に更新します（詳細については、下記のファイルセクションの$ GIT_DIR / svn / * \ * /。rev_map。*を参照してください）。

-l
--local - 地元

Do not fetch remotely; only run git rebase against the last fetched commit from the upstream SVN.リモートから取得しないでください。上流のSVNから最後にフェッチされたコミットに対してのみgit rebaseを実行します。

dcommit

Commit each diff from the current branch directly to the SVN repository, and then rebase or reset (depending on whether or not there is a diff between SVN and head). This will create a revision in SVN for each commit in Git.現在のブランチから各差分を直接SVNリポジトリにコミットしてから、リベースまたはリセットします（SVNとheadの間に差分があるかどうかに応じて）。これはGitの各コミットに対してSVNのリビジョンを作成します。

When an optional Git branch name (or a Git commit object name) is specified as an argument, the subcommand works on the specified branch, not on the current branch.オプションのGitブランチ名（またはGitコミットオブジェクト名）が引数として指定されている場合、サブコマンドは現在のブランチではなく、指定されたブランチに対して機能します。

Use of dcommit is preferred to set-tree (below).dcommitの使用はset-tree（下記）よりも好ましいです。

--no-rebase

After committing, do not rebase or reset.コミット後は、リベースしたりリセットしたりしないでください。

--commit-url <URL>

Commit to this SVN URL (the full path). This is intended to allow existing git svn repositories created with one transport method (e.g. svn:// or http:// for anonymous read) to be reused if a user is later given access to an alternate transport method (e.g. svn+ssh:// or https://) for commit.このSVN URL（フルパス）にコミットします。これは、コミットのために後で別の転送方法（またはなど）へのアクセス権がユーザーに与えられた場合に、1つの転送方法（または匿名読み取りなど）で作成された既存のgit svnリポジトリを再利用できるようにするためです。svn://http://svn+ssh://https://

config key: svn-remote.<name>.commiturl
config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)

Note that the SVN URL of the commiturl config key includes the SVN branch. If you rather want to set the commit URL for an entire SVN repository use svn-remote.<name>.pushurl instead.commiturl設定キーのSVN URLにはSVNブランチが含まれています。SVNリポジトリ全体のコミットURLを設定したい場合は、代わりにsvn-remote。<name> .pushurlを使用してください。

Using this option for any other purpose (don’t ask) is very strongly discouraged.他の目的でこのオプションを使用すること（質問しないでください）は非常にお勧めできません。

--mergeinfo=<mergeinfo> --mergeinfo = <mergeinfo>

Add the given merge information during the dcommit (e.g. --mergeinfo="/branches/foo:1-10"). All svn server versions can store this information (as a property), and svn clients starting from version 1.5 can make use of it. To specify merge information from multiple branches, use a single space character between the branches (--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8")dcommitの間に与えられたマージ情報を追加します（例--mergeinfo="/branches/foo:1-10"）。すべてのsvnサーバのバージョンはこの情報を（プロパティとして）保存することができ、バージョン1.5から始まるsvnクライアントはそれを利用することができます。複数のブランチからのマージ情報を指定するには、ブランチ間に単一のスペース文字（--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"）を使用します。

config key: svn.pushmergeinfo

This option will cause git-svn to attempt to automatically populate the svn:mergeinfo property in the SVN repository when possible. Currently, this can only be done when dcommitting non-fast-forward merges where all parents but the first have already been pushed into SVN.このオプションは、可能ならばgit-svnがSVNリポジトリのsvn：mergeinfoプロパティを自動的に設定しようとするようにします。現在、これは、最初の親を除くすべての親がすでにSVNにプッシュされている非早送りマージをコミットするときにのみ実行できます。

--interactive - インタラクティブ

Ask the user to confirm that a patch set should actually be sent to SVN. For each patch, one may answer "yes" (accept this patch), "no" (discard this patch), "all" (accept all patches), or "quit".パッチセットを実際にSVNに送信する必要があることを確認するようにユーザに依頼します。各パッチに対して、 "yes"（このパッチを承認する）、 "no"（このパッチを破棄する）、 "all"（すべてのパッチを承認する）、または "quit"と答えることができます。

git svn dcommit returns immediately if answer is "no" or "quit", without committing anything to SVN.答えが "no"または "quit"の場合、git svn dcommitはSVNに何もコミットせずに直ちに戻ります。

branch ブランチ

Create a branch in the SVN repository.SVNリポジトリにブランチを作成します。

-m
--message - メッセージ

Allows to specify the commit message.コミットメッセージを指定できます。

-t
--tag - タグ

Create a tag by using the tags_subdir instead of the branches_subdir specified during git svn init.git svn init中に指定されたbranches_subdirの代わりにtags_subdirを使用してタグを作成します。

-d<path> -d <パス>
--destination=<path> --destination = <パス>

If more than one --branches (or --tags) option was given to the init or clone command, you must provide the location of the branch (or tag) you wish to create in the SVN repository. <path> specifies which path to use to create the branch or tag and should match the pattern on the left-hand side of one of the configured branches or tags refspecs. You can see these refspecs with the commandsinitまたはcloneコマンドに複数の--branches（または--tags）オプションを指定した場合は、SVNリポジトリに作成したいブランチ（またはタグ）の場所を指定する必要があります。<path>は、ブランチまたはタグを作成するために使用するパスを指定し、構成されたブランチまたはタグのいずれかの参照仕様の左側のパターンと一致する必要があります。これらの参照仕様はコマンドで見ることができます

git config --get-all svn-remote.<name>.branches
git config --get-all svn-remote.<name>.tags

where <name> is the name of the SVN repository as specified by the -R option to init (or "svn" by default).ここで、<name>はinitの-Rオプションで指定されているSVNリポジトリの名前です（デフォルトでは "svn"）。

--username

Specify the SVN username to perform the commit as. This option overrides the username configuration property.コミットを実行するSVNユーザー名を指定してください。このオプションはusername設定プロパティを上書きします。

--commit-url

Use the specified URL to connect to the destination Subversion repository. This is useful in cases where the source SVN repository is read-only. This option overrides configuration property commiturl.指定されたURLを使用して宛先のSubversionリポジトリに接続します。これは、ソースSVNリポジトリが読み取り専用の場合に便利です。このオプションは設定プロパティcommiturlを上書きします。

git config --get-all svn-remote.<name>.commiturl
--parents - 親

Create parent folders. This parameter is equivalent to the parameter --parents on svn cp commands and is useful for non-standard repository layouts.親フォルダを作成します。このパラメータは、svn cpコマンドのパラメータ--parentsと同等で、標準以外のリポジトリレイアウトに役立ちます。

tag タグ

Create a tag in the SVN repository. This is a shorthand for branch -t.SVNリポジトリにタグを作成します。これはbranch -tの省略形です。

log ログ

This should make it easy to look up svn log messages when svn users refer to -r/--revision numbers.svnユーザが-r / - リビジョン番号を参照するとき、これはsvnログメッセージを調べるのを簡単にするはずです。

The following features from ‘svn log’ are supported:'svn log'の以下の機能がサポートされています。

-r <n>[:<n>] -r <n> [：<n>]
--revision=<n>[:<n>] --revision = <n> [：<n>]

is supported, non-numeric args are not: HEAD, NEXT, BASE, PREV, etc …​HEAD、NEXT、BASE、PREVなどがサポートされていますが、数値以外の引数はサポートされていません。

-v
--verbose - 冗談

it’s not completely compatible with the --verbose output in svn log, but reasonably close.svn logの--verboseの出力と完全な互換性はありませんが、かなり近いです。

--limit=<n> --limit = <n>

is NOT the same as --max-count, doesn’t count merged/excluded commits--max-countと同じではなく、マージ/除外されたコミットを数えません。

--incremental - 増分

supported支えられる

New features:新機能

--show-commit

shows the Git commit sha1, as wellGit commit sha1も示しています

--oneline

our version of --pretty=oneline--pretty = onelineのバージョン

Note SVN itself only stores times in UTC and nothing else. The regular svn client converts the UTC time to the local time (or based on the TZ= environment). This command has the same behaviour. SVN自体はUTCに時間を格納するだけで、他には何も格納しません。通常のsvnクライアントはUTC時間を現地時間に（またはTZ =環境に基づいて）変換します。このコマンドは同じ動作をします。

Any other arguments are passed directly to git log他の引数はすべてgit logに直接渡されます

blame 責め

Show what revision and author last modified each line of a file. The output of this mode is format-compatible with the output of ‘svn blame’ by default. Like the SVN blame command, local uncommitted changes in the working tree are ignored; the version of the file in the HEAD revision is annotated. Unknown arguments are passed directly to git blame.ファイルの各行を最後に修正したリビジョンと作成者を表示します。このモードの出力はデフォルトで 'svn blame'の出力とフォーマット互換です。SVN blameコマンドと同様に、作業ツリー内のローカルのコミットされていない変更は無視されます。HEADリビジョンのファイルのバージョンは注釈付きです。未知の引数は直接git blameに渡されます。

--git-format

Produce output in the same format as git blame, but with SVN revision numbers instead of Git commit hashes. In this mode, changes that haven’t been committed to SVN (including local working-copy edits) are shown as revision 0.git blameと同じ形式で出力を生成しますが、Gitコミットハッシュの代わりにSVNリビジョン番号を使用します。このモードでは、SVNにコミットされていない変更（ローカルの作業コピーの編集を含む）はリビジョン0として表示されます。

find-rev

When given an SVN revision number of the form rN, returns the corresponding Git commit hash (this can optionally be followed by a tree-ish to specify which branch should be searched). When given a tree-ish, returns the corresponding SVN revision number.形式rNの SVNリビジョン番号を指定すると、対応するGitコミットハッシュを返します（これには、検索対象のブランチを指定するためのツリー風のオプションを続けることができます）。ツリー風を与えると、対応するSVNリビジョン番号を返します。

-B
--before - 前

Don’t require an exact match if given an SVN revision, instead find the commit corresponding to the state of the SVN repository (on the current branch) at the specified revision.SVNリビジョンが与えられた場合に完全一致を要求するのではなく、指定されたリビジョンにおける（現在のブランチ上の）SVNリポジトリの状態に対応するコミットを探します。

-A
--after - あとで

Don’t require an exact match if given an SVN revision; if there is not an exact match return the closest match searching forward in the history.SVNリビジョンが与えられた場合、完全に一致する必要はありません。完全に一致するものがなければ、最も近いものから順に検索します。

set-tree 集合木

You should consider using dcommit instead of this command. Commit specified commit or tree objects to SVN. This relies on your imported fetch data being up to date. This makes absolutely no attempts to do patching when committing to SVN, it simply overwrites files with those specified in the tree or commit. All merging is assumed to have taken place independently of git svn functions.このコマンドの代わりにdcommitを使用することを検討してください。指定したコミットまたはツリーオブジェクトをSVNにコミットします。これはインポートされたフェッチデータが最新であることに依存します。これはSVNにコミットするときにパッチを当てようとすることは絶対にありません。単にツリーやコミットで指定されたファイルでファイルを上書きします。すべてのマージはgit svn関数とは無関係に行われたと想定されます。

create-ignore 作成 - 無視

Recursively finds the svn:ignore property on directories and creates matching .gitignore files. The resulting files are staged to be committed, but are not committed. Use -r/--revision to refer to a specific revision.ディレクトリ上のsvn：ignoreプロパティを再帰的に見つけて、一致する.gitignoreファイルを作成します。結果のファイルはコミットされるようにステージングされますが、コミットされません。特定のリビジョンを参照するには、-r / - revisionを使用します。

show-ignore 無視する

Recursively finds and lists the svn:ignore property on directories. The output is suitable for appending to the $GIT_DIR/info/exclude file.ディレクトリのsvn：ignoreプロパティを再帰的に見つけてリストにします。出力は、$ GIT_DIR / info / excludeファイルに追加するのに適しています。

mkdirs

Attempts to recreate empty directories that core Git cannot track based on information in $GIT_DIR/svn/<refname>/unhandled.log files. Empty directories are automatically recreated when using "git svn clone" and "git svn rebase", so "mkdirs" is intended for use after commands like "git checkout" or "git reset". (See the svn-remote.<name>.automkdirs config file option for more information.)コアGitが$ GIT_DIR / svn / <refname> /unhandled.logファイルの情報に基づいて追跡できない空のディレクトリを再作成しようとします。"git svn clone"や "git svn rebase"を使うと空のディレクトリが自動的に再作成されるので、 "mkdirs"は "git checkout"や "git reset"のようなコマンドの後に使うことを意図しています。（詳細についてはsvn-remote。<name> .automkdirs設定ファイルオプションを参照してください。）

commit-diff

Commits the diff of two tree-ish arguments from the command-line. This command does not rely on being inside a git svn init-ed repository. This command takes three arguments, (a) the original tree to diff against, (b) the new tree result, (c) the URL of the target Subversion repository. The final argument (URL) may be omitted if you are working from a git svn-aware repository (that has been init-ed with git svn). The -r<revision> option is required for this.コマンドラインからの2つのツリー風引数の差分をコミットします。このコマンドはgit svn init-edリポジトリ内にあることに依存しません。このコマンドは3つの引数、（a）元の差分ツリー、（b）新しいツリーの結果、（c）ターゲットSubversionリポジトリのURLを取ります。git svn対応のリポジトリ（git svnでinit -ed されている）から作業している場合は、最後の引数（URL）を省略することができます。これには-r <revision>オプションが必要です。

The commit message is supplied either directly with the -m or -F option, or indirectly from the tag or commit when the second tree-ish denotes such an object, or it is requested by invoking an editor (see --edit option below).コミットメッセージは、-mor -Fオプションと直接、または2番目のツリーがそのようなオブジェクトを示すときにタグまたはコミットから間接的に提供されるか、エディタを呼び出すことによって要求され--editます（下記のオプションを参照）。

-m <msg>
--message=<msg> --message = <msg>

Use the given msg as the commit message. This option disables the --edit option.msgコミットメッセージとして与えられたを使用してください。このオプションはオプションを無効にし--editます。

-F <filename> -F <ファイル名>
--file=<filename> --file = <ファイル名>

Take the commit message from the given file. This option disables the --edit option.与えられたファイルからコミットメッセージを取ります。このオプションはオプションを無効にし--editます。

info 情報

Shows information about a file or directory similar to what ‘svn info’ provides. Does not currently support a -r/--revision argument. Use the --url option to output only the value of the URL: field.'svn info'が提供するものと同様のファイルまたはディレクトリに関する情報を表示します。現在、-r / - revision引数をサポートしていません。URL：フィールドの値だけを出力するには、 - urlオプションを使用します。

proplist 支持者

Lists the properties stored in the Subversion repository about a given file or directory. Use -r/--revision to refer to a specific Subversion revision.特定のファイルまたはディレクトリについてSubversionリポジトリに格納されているプロパティを一覧表示します。特定のSubversionリビジョンを参照するには、-r / - revisionを使用します。

propget 支える

Gets the Subversion property given as the first argument, for a file. A specific revision can be specified with -r/--revision.ファイルの最初の引数として指定されたSubversionプロパティを取得します。特定のリビジョンは-r / - revisionで指定できます。

propset 支柱

Sets the Subversion property given as the first argument, to the value given as the second argument for the file given as the third argument.最初の引数として指定されたSubversionプロパティを、3番目の引数として指定されたファイルの2番目の引数として指定された値に設定します。

Example:例：

git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile

This will set the property svn:keywords to FreeBSD=%H for the file devel/py-tipper/Makefile.これにより、devel / py-tipper / Makefileファイルのプロパティsvn：keywordsがFreeBSD =％Hに設定されます。

show-externals 見本外

Shows the Subversion externals. Use -r/--revision to specify a specific revision.Subversionの外観を表示します。特定のリビジョンを指定するには、-r / - revisionを使用します。

gc GC

Compress $GIT_DIR/svn/<refname>/unhandled.log files and remove $GIT_DIR/svn/<refname>/index files.$ GIT_DIR / svn / <refname> /unhandled.logファイルを圧縮し、$ GIT_DIR / svn / <refname> / indexファイルを削除します。

reset リセット

Undoes the effects of fetch back to the specified revision. This allows you to re-fetch an SVN revision. Normally the contents of an SVN revision should never change and reset should not be necessary. However, if SVN permissions change, or if you alter your --ignore-paths option, a fetch may fail with "not found in commit" (file not previously visible) or "checksum mismatch" (missed a modification). If the problem file cannot be ignored forever (with --ignore-paths) the only way to repair the repo is to use reset.指定したリビジョンにフェッチした効果を元に戻します。これにより、SVNリビジョンを再取得することができます。通常、SVNリビジョンの内容は決して変更されるべきではなく、リセットする必要はないはずです。ただし、SVNのアクセス権が変更された場合、または--ignore-pathsオプションを変更した場合、フェッチは「コミットに見つからない」（ファイルが以前に表示されていない）または「チェックサムの不一致」（変更を見逃した）で失敗する場合があります。問題のファイルを永遠に無視できない場合（--ignore-paths）、リポジトリを修復する唯一の方法はresetを使用することです。

Only the rev_map and refs/remotes/git-svn are changed (see $GIT_DIR/svn/*\*/.rev_map.* in the FILES section below for details). Follow reset with a fetch and then git reset or git rebase to move local branches onto the new tree.rev_mapとrefs / remotes / git-svnだけが変更されます（詳細は下記のファイルセクションの$ GIT_DIR / svn / * \ * /。rev_map。*を参照してください）。フォローリセットでフェッチ当時とgitのリセットやgitのリベース新しいツリー上にローカルの枝を移動すること。

-r <n>
--revision=<n> --revision = <n>

Specify the most recent revision to keep. All later revisions are discarded.保持する最新のリビジョンを指定してください。それ以降のすべてのリビジョンは破棄されます。

-p
--parent - 親

Discard the specified revision as well, keeping the nearest parent instead.指定されたリビジョンも破棄し、代わりに最も近い親を保持します。

Example: 例：

Assume you have local changes in "master", but you need to refetch "r2"."master"にローカルな変更があると仮定しますが、 "r2"を再フェッチする必要があります。

    r1---r2---r3 remotes/git-svn
                \
                 A---B master

Fix the ignore-paths or SVN permissions problem that caused "r2" to be incomplete in the first place. Then:そもそも "r2"が不完全になる原因となっていたignore-pathsやSVNのパーミッションの問題を修正しました。その後：

git svn reset -r2 -p
git svn fetch
    r1---r2'--r3' remotes/git-svn
      \
       r2---r3---A---B master

Then fixup "master" with git rebase. Do NOT use git merge or your history will not be compatible with a future dcommit!それからgit rebaseで "master"を修正してください。git mergeを使わないでください。さもないとあなたの履歴は将来のdcommitと互換性がなくなるでしょう！

git rebase --onto remotes/git-svn A^ master
    r1---r2'--r3' remotes/git-svn
                \
                 A'--B' master

OPTIONSオプション

--shared[=(false|true|umask|group|all|world|everybody)] --shared [=（false | true | umask |グループ| all | world | everybody）]]
--template=<template_directory> --template = <template_directory>

Only used with the init command. These are passed directly to git init.initコマンドでのみ使用されます。これらは直接git initに渡されます。

-r <arg> -r <引数>
--revision <arg>

Used with the fetch command.fetchコマンドと共に使用します。

This allows revision ranges for partial/cauterized history to be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges), $NUMBER:HEAD, and BASE:$NUMBER are all supported.これにより、部分的な履歴または焼灼された履歴の改訂範囲をサポートすることができます。$ NUMBER、$ NUMBER1：$ NUMBER2（数値範囲）、$ NUMBER：HEAD、およびBASE：$ NUMBERはすべてサポートされています。

This can allow you to make partial mirrors when running fetch; but is generally not recommended because history will be skipped and lost.これにより、fetchを実行するときに部分的なミラーを作成できます。しかし、履歴はスキップされ失われるため、一般的にはお勧めできません。

-
--stdin

Only used with the set-tree command.set-treeコマンドでのみ使用されます。

Read a list of commits from stdin and commit them in reverse order. Only the leading sha1 is read from each line, so git rev-list --pretty=oneline output can be used.標準入力からコミットのリストを読み、それらを逆の順序でコミットします。先頭のsha1だけが各行から読み取られるので、git rev-list --pretty = onelineの出力を使用できます。

--rmdir

Only used with the dcommit, set-tree and commit-diff commands.dcommit、set-tree、およびcommit-diffコマンドでのみ使用されます。

Remove directories from the SVN tree if there are no files left behind. SVN can version empty directories, and they are not removed by default if there are no files left in them. Git cannot version empty directories. Enabling this flag will make the commit to SVN act like Git.残っているファイルがない場合は、SVNツリーからディレクトリを削除します。SVNは空のディレクトリをバージョン管理することができ、ファイルが残っていなければデフォルトで削除されません。Gitは空のディレクトリをバージョン管理することはできません。このフラグを有効にすると、SVNへのコミットがGitのように機能します。

config key: svn.rmdir
-e
--edit - 編集

Only used with the dcommit, set-tree and commit-diff commands.dcommit、set-tree、およびcommit-diffコマンドでのみ使用されます。

Edit the commit message before committing to SVN. This is off by default for objects that are commits, and forced on when committing tree objects.SVNにコミットする前にコミットメッセージを編集します。コミットされているオブジェクトの場合、これはデフォルトでオフになり、ツリーオブジェクトをコミットするときに強制的にオンになります。

config key: svn.edit
-l<num> -l <番号>
--find-copies-harder

Only used with the dcommit, set-tree and commit-diff commands.dcommit、set-tree、およびcommit-diffコマンドでのみ使用されます。

They are both passed directly to git diff-tree; see git-diff-tree[1] for more information.どちらもgit diff-treeに直接渡されます。詳しくはgit-diff-tree [1]をご覧ください。

config key: svn.l
config key: svn.findcopiesharder
-A<filename> -A <ファイル名>
--authors-file=<filename> --authors-file = <ファイル名>

Syntax is compatible with the file used by git cvsimport but an empty email address can be supplied with <>:構文はgit cvsimportで使用されるファイルと互換性がありますが、空の電子メールアドレスを<>で指定できます。

	loginname = Joe User <user@example.com>

If this option is specified and git svn encounters an SVN committer name that does not exist in the authors-file, git svn will abort operation. The user will then have to add the appropriate entry. Re-running the previous git svn command after the authors-file is modified should continue operation.このオプションが指定されていて、git svnがauthors-fileに存在しないSVNコミッタ名を見つけた場合、git svnは操作を中止します。その後、ユーザーは適切なエントリを追加する必要があります。authors-fileが変更された後に前のgit svnコマンドを再実行すると、操作が続行されます。

config key: svn.authorsfile
--authors-prog=<filename> --authors-prog = <ファイル名>

If this option is specified, for each SVN committer name that does not exist in the authors file, the given file is executed with the committer name as the first argument. The program is expected to return a single line of the form "Name <email>" or "Name <>", which will be treated as if included in the authors file.このオプションを指定すると、authorsファイルに存在しない各SVNコミッター名に対して、最初の引数としてコミッター名を指定して指定のファイルが実行されます。プログラムは、 "Name <email>"または "Name <>"の形式の単一行を返すことが期待されています。これらは、作成者ファイルに含まれているかのように扱われます。

Due to historical reasons a relative filename is first searched relative to the current directory for init and clone and relative to the root of the working tree for fetch. If filename is not found, it is searched like any other command in $PATH.歴史的な理由により、相対ファイル名は最初にinitとcloneではカレントディレクトリを基準に、fetchでは作業ツリーのルートを基準にして検索されます。filenameが見つからない場合は、$ PATHの他のコマンドと同じように検索されます。

config key: svn.authorsProg
-q
--quiet - 静か

Make git svn less verbose. Specify a second time to make it even less verbose.作るのgitのsvnはそれほど冗長。さらに冗長にするには、もう一度指定します。

-m
--merge - マージ
-s<strategy> -s <戦略>
--strategy=<strategy> --strategy = <strategy>
-p
--preserve-merges --preserve-merge

These are only used with the dcommit and rebase commands.これらはdcommitおよびrebaseコマンドでのみ使用されます。

Passed directly to git rebase when using dcommit if a git reset cannot be used (see dcommit).gitリセットが使用できない場合、dcommitを使用するときにgit rebaseに直接渡されます（dcommitを参照）。

-n
--dry-run

This can be used with the dcommit, rebase, branch and tag commands.これは、dcommit、rebase、branch、およびtagコマンドと一緒に使用できます。

For dcommit, print out the series of Git arguments that would show which diffs would be committed to SVN.dcommit、SVNにコミットされるであろう差分表示されるでしょうGitの一連の引数をプリントアウトします。

For rebase, display the local branch associated with the upstream svn repository associated with the current branch and the URL of svn repository that will be fetched from.ためリベース、現在のブランチからフェッチされるSVNリポジトリのURLに関連付けられた上流SVNリポジトリに関連付けられているローカルブランチを表示します。

For branch and tag, display the urls that will be used for copying when creating the branch or tag.以下のためのブランチとタグ、ブランチやタグを作成するときに、コピーに使用されるURLを表示します。

--use-log-author

When retrieving svn commits into Git (as part of fetch, rebase, or dcommit operations), look for the first From: or Signed-off-by: line in the log message and use that as the author string.svnコミットをGitに取り込むとき（フェッチ、リベース、またはdcommit操作の一部として）、ログメッセージの最初From:またはSigned-off-by:一行を探し、それを作者文字列として使います。

config key: svn.useLogAuthor
--add-author-from

When committing to svn from Git (as part of set-tree or dcommit operations), if the existing log message doesn’t already have a From: or Signed-off-by: line, append a From: line based on the Git commit’s author string. If you use this, then --use-log-author will retrieve a valid author string for all commits.（set-treeまたはdcommit操作の一部として）Gitからsvnをコミットするとき、既存のログメッセージにまだFrom:or Signed-off-by:行がない場合はFrom:、Gitコミットの作成者文字列に基づいて行を追加します。これを使用すると、--use-log-authorすべてのコミットに対して有効な作者文字列を取得します。

config key: svn.addAuthorFrom

ADVANCED OPTIONS高度なオプション

-i<GIT_SVN_ID> -i <GIT_SVN_ID>
--id <GIT_SVN_ID>

This sets GIT_SVN_ID (instead of using the environment). This allows the user to override the default refname to fetch from when tracking a single URL. The log and dcommit commands no longer require this switch as an argument.これはGIT_SVN_IDを設定します（環境を使用する代わりに）。これにより、ユーザーは単一のURLを追跡するときに取得するデフォルトのrefnameをオーバーライドできます。ログとdcommitはもはや引数としてこのスイッチを必要とするコマンドはありません。

-R<remote name> -R <リモート名>
--svn-remote <remote name> --svn-remote <リモート名>

Specify the [svn-remote "<remote name>"] section to use, this allows SVN multiple repositories to be tracked. Default: "svn"使用する[svn-remote "<remote name>"]セクションを指定します。これにより、SVNの複数のリポジトリを追跡できます。デフォルト： "svn"

--follow-parent - フォロー親

This option is only relevant if we are tracking branches (using one of the repository layout options --trunk, --tags, --branches, --stdlayout). For each tracked branch, try to find out where its revision was copied from, and set a suitable parent in the first Git commit for the branch. This is especially helpful when we’re tracking a directory that has been moved around within the repository. If this feature is disabled, the branches created by git svn will all be linear and not share any history, meaning that there will be no information on where branches were branched off or merged. However, following long/convoluted histories can take a long time, so disabling this feature may speed up the cloning process. This feature is enabled by default, use --no-follow-parent to disable it.このオプションは、（リポジトリレイアウトオプション--trunk、--tags、--branches、 - stdlayoutのいずれかを使用して）ブランチを追跡している場合にのみ関係します。追跡された各ブランチについて、そのリビジョンがどこからコピーされたのかを調べ、ブランチに対する最初のGitコミットで適切な親を設定します。これは、リポジトリ内を移動したディレクトリを追跡しているときに特に役立ちます。この機能を無効にすると、git svnによって作成されたブランチはすべて線形になり、履歴を共有しなくなります。つまり、ブランチが分岐またはマージされた場所に関する情報はありません。ただし、長い/複雑な履歴をたどると長い時間がかかることがあるため、この機能を無効にするとクローン作成プロセスが高速化する可能性があります。この機能はデフォルトで有効になっています。無効にするには--no-follow-parentを使用します。

config key: svn.followparent

CONFIG FILE-ONLY OPTIONSファイルのみのオプションの設定

svn.noMetadata
svn-remote.<name>.noMetadata svn-remote。<名前> .noMetadata

This gets rid of the git-svn-id: lines at the end of every commit.これは全てのコミットの終わりにgit-svn-id：行を取り除きます。

This option can only be used for one-shot imports as git svn will not be able to fetch again without metadata. Additionally, if you lose your $GIT_DIR/svn/*\*/.rev_map.* files, git svn will not be able to rebuild them.git svnはメタデータなしで再び取得することはできないので、このオプションはワンショットインポートにのみ使用できます。さらに、あなたがあなたの$ GIT_DIR / svn / * \ * /。rev_map。*ファイルを失った場合、git svnはそれらを再構築することができません。

The git svn log command will not work on repositories using this, either. Using this conflicts with the useSvmProps option for (hopefully) obvious reasons.gitのsvnのログコマンドはどちらか、これを使用してリポジトリでは動作しません。（うまくいけば）明白な理由でuseSvmPropsオプションとこれを使用することは衝突します。

This option is NOT recommended as it makes it difficult to track down old references to SVN revision numbers in existing documentation, bug reports and archives. If you plan to eventually migrate from SVN to Git and are certain about dropping SVN history, consider git-filter-branch[1] instead. filter-branch also allows reformatting of metadata for ease-of-reading and rewriting authorship info for non-"svn.authorsFile" users.このオプションは、既存のドキュメンテーション、バグレポート、およびアーカイブの中でSVNリビジョン番号への古い参照を追跡するのを困難にするのでお勧めできません。最終的にSVNからGitに移行する予定で、SVN履歴を削除することが確実である場合は、代わりにgit-filter-branch [1]を検討してください。filter-branchは、 "svn.authorsFile"以外のユーザーのために、読みやすさや作成者情報を書き換えるためのメタデータの再フォーマットも可能にします。

svn.useSvmProps
svn-remote.<name>.useSvmProps svn-remote。<名前> .useSvmProps

This allows git svn to re-map repository URLs and UUIDs from mirrors created using SVN::Mirror (or svk) for metadata.これにより、git svnは SVN :: Mirror（またはsvk）を使ってメタデータ用に作成されたミラーからリポジトリURLとUUIDを再マッピングすることができます。

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リビジョンが "svm：headrev"というプロパティを持っている場合、そのリビジョンはSVN :: Mirrorによって作成されたものと考えられます（SVKでも使用されています）。このプロパティには、リポジトリのUUIDとリビジョンが含まれています。元のURLをミラーリングしているように見せたいので、元のID URLとUUIDを返すヘルパー関数を導入し、コミットメッセージでメタデータを生成するときにそれを使用します。

svn.useSvnsyncProps
svn-remote.<name>.useSvnsyncprops svn-remote。<名前> .useSvnsyncprops

Similar to the useSvmProps option; this is for users of the svnsync(1) command distributed with SVN 1.4.x and later.useSvmPropsオプションと同様です。これはSVN 1.4.x以降で配布されているsvnsync（1）コマンドのユーザ向けです。

svn-remote.<name>.rewriteRoot svn-remote。<名前> .rewriteRoot

This allows users to create repositories from alternate URLs. For example, an administrator could run git svn on the server locally (accessing via file://) but wish to distribute the repository with a public http:// or svn:// URL in the metadata so users of it will see the public URL.これにより、ユーザーは代替URLからリポジトリを作成できます。たとえば、管理者はサーバー上でgit svnをローカルで（file：//経由でアクセスして）実行することができますが、メタデータの公開http：//またはsvn：// URLを使用してリポジトリを配布したい場合公開URL

svn-remote.<name>.rewriteUUID svn-remote。<名前> .rewriteUUID

Similar to the useSvmProps option; this is for users who need to remap the UUID manually. This may be useful in situations where the original UUID is not available via either useSvmProps or useSvnsyncProps.useSvmPropsオプションと同様です。これは、UUIDを手動で再マッピングする必要があるユーザーのためのものです。これは、元のUUIDがuseSvmPropsまたはuseSvnsyncPropsのどちらでも利用できない状況で役立ちます。

svn-remote.<name>.pushurl svn-remote。<名前> .pushurl

Similar to Git’s remote.<name>.pushurl, this key is designed to be used in cases where url points to an SVN repository via a read-only transport, to provide an alternate read/write transport. It is assumed that both keys point to the same repository. Unlike commiturl, pushurl is a base path. If either commiturl or pushurl could be used, commiturl takes precedence.Gitと同様にremote.<name>.pushurl、このキーはurlが読み取り専用のトランスポートを介してSVNリポジトリを指している場合に使用され、代替の読み取り/書き込みトランスポートを提供します。両方のキーが同じリポジトリを指すと仮定します。commiturlとは異なり、pushurlは基本パスです。commiturlまたはpushurlのいずれかを使用できる場合は、commiturlが優先されます。

svn.brokenSymlinkWorkaround svn.brokenSymlink回避策

This disables potentially expensive checks to workaround broken symlinks checked into SVN by broken clients. Set this option to "false" if you track a SVN repository with many empty blobs that are not symlinks. This option may be changed while git svn is running and take effect on the next revision fetched. If unset, git svn assumes this option to be "true".これは壊れたクライアントによってSVNにチェックインされた壊れたシンボリックリンクを回避するための潜在的に高価なチェックを無効にします。シンボリックリンクではない空のBLOBが多数あるSVNリポジトリを追跡する場合は、このオプションを "false"に設定します。このオプションはgit svnの実行中に変更され、次にフェッチされたリビジョンで有効になります。設定されていない場合、git svnはこのオプションが "true"であると見なします。

svn.pathnameencoding

This instructs git svn to recode pathnames to a given encoding. It can be used by windows users and by those who work in non-utf8 locales to avoid corrupted file names with non-ASCII characters. Valid encodings are the ones supported by Perl’s Encode module.これはgit svnにパス名を与えられたエンコーディングに変換するように指示します。これは、Windowsユーザや、非ASCII文字を含むファイル名の破損を避けるために、非UTF-8ロケールで作業するユーザが使用できます。有効なエンコーディングはPerlのEncodeモジュールによってサポートされているものです。

svn-remote.<name>.automkdirs svn-remote。<名前> .automkdirs

Normally, the "git svn clone" and "git svn rebase" commands attempt to recreate empty directories that are in the Subversion repository. If this option is set to "false", then empty directories will only be created if the "git svn mkdirs" command is run explicitly. If unset, git svn assumes this option to be "true".通常、 "git svn clone"と "git svn rebase"コマンドはSubversionリポジトリにある空のディレクトリを再作成しようとします。このオプションが "false"に設定されていると、 "git svn mkdirs"コマンドが明示的に実行された場合にのみ空のディレクトリが作成されます。設定されていない場合、git svnはこのオプションが "true"であると見なします。

Since the noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps and useSvmProps options all affect the metadata generated and used by git svn; they must be set in the configuration file before any history is imported and these settings should never be changed once they are set.noMetadata、rewriteRoot、rewriteUUID、useSvnsyncProps、およびuseSvmPropsオプションはすべて、git svnによって生成および使用されるメタデータに影響します。彼らは必要があります任意の履歴をインポートする前に、設定ファイルで設定され、それらが設定されると、これらの設定を変更すべきではありません。

Additionally, only one of these options can be used per svn-remote section because they affect the git-svn-id: metadata line, except for rewriteRoot and rewriteUUID which can be used together.さらに、reitRootとrewriteUUIDを同時に使用できる場合を除き、これらのオプションのうち1つだけがsvn-remoteセクションごとに使用できます。これは、git-svn-id：メタデータ行に影響するためです。

BASIC EXAMPLES基本例

Tracking and contributing to the trunk of a Subversion-managed project (ignoring tags and branches):Subversionで管理されているプロジェクトのトランクを追跡して貢献する（タグとブランチを無視する）：

# Clone a repo (like git clone):
	git svn clone http://svn.example.com/project/trunk
# Enter the newly cloned directory:
	cd trunk
# You should be on master branch, double-check with 'git branch'
	git branch
# Do some work and commit locally to Git:
	git commit ...
# Something is committed to SVN, rebase your local changes against the
# latest changes in SVN:
	git svn rebase
# Now commit your changes (that were committed previously using Git) to SVN,
# as well as automatically updating your working HEAD:
	git svn dcommit
# Append svn:ignore settings to the default Git exclude file:
	git svn show-ignore >> .git/info/exclude

Tracking and contributing to an entire Subversion-managed project (complete with a trunk, tags and branches):Subversionで管理されたプロジェクト全体の追跡と貢献（トランク、タグ、ブランチを完備）：

# Clone a repo with standard SVN directory layout (like git clone):
	git svn clone http://svn.example.com/project --stdlayout --prefix svn/
# Or, if the repo uses a non-standard directory layout:
	git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
# View all branches and tags you have cloned:
	git branch -r
# Create a new branch in SVN
	git svn branch waldo
# Reset your master to trunk (or any other branch, replacing 'trunk'
# with the appropriate name):
	git reset --hard svn/trunk
# You may only dcommit to one branch/tag/trunk at a time.  The usage
# of dcommit/rebase/show-ignore should be the same as above.

The initial git svn clone can be quite time-consuming (especially for large Subversion repositories). If multiple people (or one person with multiple machines) want to use git svn to interact with the same Subversion repository, you can do the initial git svn clone to a repository on a server and have each person clone that repository with git clone:初期のgit svnクローンはかなり時間がかかる可能性があります（特に大規模なSubversionリポジトリの場合）。複数の人（または複数のマシンを持つ1人）が同じSubversionリポジトリとやり取りするためにgit svnを使用したい場合は、最初のgit svnクローンをサーバー上のリポジトリに作成し、各人にそのリポジトリをgit cloneでクローンさせることができます。

# Do the initial import on a server
	ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
# Clone locally - make sure the refs/remotes/ space matches the server
	mkdir project
	cd project
	git init
	git remote add origin server:/pub/project
	git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
	git fetch
# Prevent fetch/pull from remote Git server in the future,
# we only want to use git svn for future updates
	git config --remove-section remote.origin
# Create a local branch from one of the branches just fetched
	git checkout -b master FETCH_HEAD
# Initialize 'git svn' locally (be sure to use the same URL and
# --stdlayout/-T/-b/-t/--prefix options as were used on server)
	git svn init http://svn.example.com/project [options...]
# Pull the latest changes from Subversion
	git svn rebase

REBASE VS. PULL/MERGEREBASE VS. プル/マージ

Prefer to use git svn rebase or git rebase, rather than git pull or git merge to synchronize unintegrated commits with a git svn branch. Doing so will keep the history of unintegrated commits linear with respect to the upstream SVN repository and allow the use of the preferred git svn dcommit subcommand to push unintegrated commits back into SVN.統合されていないコミットをgit svnブランチと同期させるためにgit pullやgit mergeよりもgit svn rebaseやgit rebaseを使うことをお勧めします。そうすることで、統合されていないコミットの履歴を上流のSVNリポジトリに対して線形に保ち、優先されるgit svn dcommitサブコマンドを使用して統合されていないコミットをSVNに戻すことができます。

Originally, git svn recommended that developers pulled or merged from the git svn branch. This was because the author favored git svn set-tree B to commit a single head rather than the git svn set-tree A..B notation to commit multiple commits. Use of git pull or git merge with git svn set-tree A..B will cause non-linear history to be flattened when committing into SVN and this can lead to merge commits unexpectedly reversing previous commits in SVN.もともと、git svnは開発者がgit svnブランチからプルまたはマージすることを推奨していました。これは、著者が複数のコミットをコミットするgit svn set-tree Bというgit svn set-tree A..B表記よりも単一のヘッドをコミットする方が好まれたためです。git pullまたはgit merge with git svn set-tree A..Bを使用すると、SVNにコミットするときに非線形履歴が平坦化されるため、SVNの以前のコミットが予期せずにマージコミットに逆戻りすることがあります。

MERGE TRACKINGマージトラッキング

While git svn can track copy history (including branches and tags) for repositories adopting a standard layout, it cannot yet represent merge history that happened inside git back upstream to SVN users. Therefore it is advised that users keep history as linear as possible inside Git to ease compatibility with SVN (see the CAVEATS section below).一方でGitのSVNは、標準レイアウトを採用するリポジトリの（ブランチやタグを含む）のコピーの履歴を追跡することができ、それはまだSVNのユーザーに戻って上流Gitの内部で起こったマージの歴史を表現することはできません。したがって、SVNとの互換性を容易にするために、ユーザーはGit内で可能な限り線形に履歴を保持することをお勧めします（下記の「警告」セクションを参照）。

HANDLING OF SVN BRANCHESSVNブランチの取り扱い

If git svn is configured to fetch branches (and --follow-branches is in effect), it sometimes creates multiple Git branches for one SVN branch, where the additional branches have names of the form branchname@nnn (with nnn an SVN revision number). These additional branches are created if git svn cannot find a parent commit for the first commit in an SVN branch, to connect the branch to the history of the other branches.git svnがブランチを取得するように設定されている場合（そして--follow-branchesが有効な場合）、1つのSVNブランチに対して複数のGitブランチを作成することがあります。追加ブランチの名前はbranchname @ nnnです（nnnはSVNリビジョン番号） ）git svnがSVNブランチの最初のコミットのための親コミットを見つけることができない場合、これらの追加のブランチは作成され、ブランチを他のブランチの履歴に接続します。

Normally, the first commit in an SVN branch consists of a copy operation. git svn will read this commit to get the SVN revision the branch was created from. It will then try to find the Git commit that corresponds to this SVN revision, and use that as the parent of the branch. However, it is possible that there is no suitable Git commit to serve as parent. This will happen, among other reasons, if the SVN branch is a copy of a revision that was not fetched by git svn (e.g. because it is an old revision that was skipped with --revision), or if in SVN a directory was copied that is not tracked by git svn (such as a branch that is not tracked at all, or a subdirectory of a tracked branch). In these cases, git svn will still create a Git branch, but instead of using an existing Git commit as the parent of the branch, it will read the SVN history of the directory the branch was copied from and create appropriate Git commits. This is indicated by the message "Initializing parent: <branchname>".通常、SVNブランチの最初のコミットはコピー操作で構成されています。git svnはこのコミットを読んでブランチの作成元のSVNリビジョンを取得します。それはそれからこのSVNリビジョンに対応するGitコミットを見つけようとし、それをブランチの親として使用します。ただし、親として機能するための適切なGitコミットがない可能性があります。これは、SVNブランチがgit svnによってフェッチされなかったリビジョンのコピーである場合（例えば、スキップされた古いリビジョンであるため--revision）、またはSVNでコピーされていないディレクトリがコピーされた場合に起こります。git svnによって追跡されます（まったく追跡されないブランチ、追跡されたブランチのサブディレクトリなど）。このような場合、git svnそれでもGitブランチを作成しますが、ブランチの親として既存のGitコミットを使用する代わりに、ブランチのコピー元ディレクトリのSVN履歴を読み取り、適切なGitコミットを作成します。これは、メッセージ「Initializing parent：<branchname>」によって示されます。

Additionally, it will create a special branch named <branchname>@<SVN-Revision>, where <SVN-Revision> is the SVN revision number the branch was copied from. This branch will point to the newly created parent commit of the branch. If in SVN the branch was deleted and later recreated from a different version, there will be multiple such branches with an @.さらに、<branchname> @ <SVN-Revision>という名前の特別なブランチが作成されます。<SVN-Revision>は、ブランチのコピー元のSVNリビジョン番号です。このブランチは、ブランチの新しく作成された親コミットを指します。SVNでブランチが削除され、後で別のバージョンから再作成された場合は、@を持つそのようなブランチが複数存在します。

Note that this may mean that multiple Git commits are created for a single SVN revision.これは複数のGitコミットが単一のSVNリビジョンに対して作成されることを意味するかもしれないことに注意してください。

An example: in an SVN repository with a standard trunk/tags/branches layout, a directory trunk/sub is created in r.100. In r.200, trunk/sub is branched by copying it to branches/. git svn clone -s will then create a branch sub. It will also create new Git commits for r.100 through r.199 and use these as the history of branch sub. Thus there will be two Git commits for each revision from r.100 to r.199 (one containing trunk/, one containing trunk/sub/). Finally, it will create a branch sub@200 pointing to the new parent commit of branch sub (i.e. the commit for r.200 and trunk/sub/).例：標準のtrunk / tags / branchesレイアウトのSVNリポジトリでは、ディレクトリtrunk / subがr.100に作成されます。r.200では、trunk / subはbranches /にコピーすることで分岐します。git svn clone -sはそれからbranch subを作成します。また、r.100からr.199までの新しいGitコミットを作成し、それらをbranch subの履歴として使用します。したがって、r.100からr.199までの各リビジョンに対して2つのGitコミットがあります（1つはtrunk /を含み、もう1つはtrunk / sub /を含みます）。最後に、それはブランチが作成されます200 @サブブランチのコミット新しい親にポインティングサブ（すなわちr.200とトランク/サブ/のコミット）。

CAVEATS警告

For the sake of simplicity and interoperating with Subversion, it is recommended that all git svn users clone, fetch and dcommit directly from the SVN server, and avoid all git clone/pull/merge/push operations between Git repositories and branches. The recommended method of exchanging code between Git branches and users is git format-patch and git am, or just 'dcommit’ing to the SVN repository.簡潔にし、Subversionと相互運用するために、すべてのgit svnユーザーはSVNサーバーから直接クローン作成、フェッチ、そしてdcommitを行い、Gitリポジトリとブランチ間のすべてのgit clone / pull / merge / push操作を避けるようにしてください。Gitブランチとユーザーの間でコードを交換するのに推奨される方法はgit format-patchとgit am、あるいは単にSVNリポジトリに 'dcommit'することです。

Running git merge or git pull is NOT recommended on a branch you plan to dcommit from because Subversion users cannot see any merges you’ve made. Furthermore, if you merge or pull from a Git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch.Subversionのユーザは自分が行ったマージを見ることができないので、git mergeやgit pullを実行することはあなたがdcommitする予定のブランチではお勧めできません。さらに、SVNブランチのミラーであるGitブランチからマージまたはプルすると、dcommitは間違ったブランチにコミットする可能性があります。

If you do merge, note the following rule: git svn dcommit will attempt to commit on top of the SVN commit named inマージする場合は、次の規則に注意してください。git svn dcommitは、で指定されたSVNコミットに加えてコミットを試みます。

git log --grep=^git-svn-id: --first-parent -1

You must therefore ensure that the most recent commit of the branch you want to dcommit to is the first parent of the merge. Chaos will ensue otherwise, especially if the first parent is an older commit on the same SVN branch.したがって、dcommitしたいブランチの最新のコミットがマージの最初の親であることを確認する必要があります。特に最初の親が同じSVNブランチに対するより古いコミットである場合、それ以外の場合は混乱が起こります。

git clone does not clone branches under the refs/remotes/ hierarchy or any git svn metadata, or config. So repositories created and managed with using git svn should use rsync for cloning, if cloning is to be done at all.git cloneは、refs / remotes / hierarchyやgit svnメタデータ、あるいはconfigの下にブランチをクローンすることはしません。そのため、git svnを使用して作成および管理されているリポジトリでは、クローン作成をまったく行わない場合は、クローン作成にrsyncを使用する必要があります。

Since dcommit uses rebase internally, any Git branches you git push to before dcommit on will require forcing an overwrite of the existing ref on the remote repository. This is generally considered bad practice, see the git-push[1] documentation for details.以来dcommitは、あなたが、内部的にリベース任意のGitのブランチを使用してgitのプッシュ前にdcommitリモートリポジトリ上の既存のREFの上書きを強制する必要があります上。これは一般に悪い習慣と考えられています。詳細についてはgit-push [1]ドキュメントを参照してください。

Do not use the --amend option of git-commit[1] on a change you’ve already dcommitted. It is considered bad practice to --amend commits you’ve already pushed to a remote repository for other users, and dcommit with SVN is analogous to that.git-commit [1]の--amendオプションは、既にコミットした変更には使用しないでください。 - 他のユーザのためにリモートリポジトリにすでにプッシュしているコミットを--amendすることは悪い習慣と考えられています、そしてSVNとのdcommitはそれに似ています。

When cloning an SVN repository, if none of the options for describing the repository layout is used (--trunk, --tags, --branches, --stdlayout), git svn clone will create a Git repository with completely linear history, where branches and tags appear as separate directories in the working copy. While this is the easiest way to get a copy of a complete repository, for projects with many branches it will lead to a working copy many times larger than just the trunk. Thus for projects using the standard directory structure (trunk/branches/tags), it is recommended to clone with option --stdlayout. If the project uses a non-standard structure, and/or if branches and tags are not required, it is easiest to only clone one directory (typically trunk), without giving any repository layout options. If the full history with branches and tags is required, the options --trunk / --branches / --tags must be used.SVNリポジトリを複製するとき、リポジトリのレイアウトを記述するためのオプション（--trunk、--tags、--branches、 - stdlayout）のいずれも使用されていない場合、git svn cloneは完全に線形の履歴を持つGitリポジトリを作成します。作業コピーでは、ブランチとタグは別々のディレクトリとして表示されます。これが完全なリポジトリのコピーを取得する最も簡単な方法ですが、多くのブランチを持つプロジェクトの場合は、単なるトランクよりも何倍も大きな作業コピーが作成されることになります。したがって、標準のディレクトリ構造（trunk / branches / tags）を使用しているプロジェクトの場合は、オプションでクローンを作成することをお勧めします。--stdlayout。プロジェクトが標準以外の構造を使用している場合や、ブランチやタグが不要な場合は、リポジトリのレイアウトオプションを指定せずに1つのディレクトリ（通常はトランク）のみを複製するのが最も簡単です。ブランチとタグを含む完全な履歴が必要な場合は、オプション--trunk/ --branches/を--tags使用する必要があります。

When using multiple --branches or --tags, git svn does not automatically handle name collisions (for example, if two branches from different paths have the same name, or if a branch and a tag have the same name). In these cases, use init to set up your Git repository then, before your first fetch, edit the $GIT_DIR/config file so that the branches and tags are associated with different name spaces. For example:複数の--branchesまたは--tagsを使用する場合、git svnは自動的に名前の衝突を処理しません（たとえば、異なるパスからの2つのブランチが同じ名前を持つ場合、またはブランチとタグが同じ名前を持つ場合）。このような場合は、initを使用してGitリポジトリを設定してから、最初の取得の前に、ブランチとタグが異なるネームスペースに関連付けられるように$ GIT_DIR / configファイルを編集します。例えば：

branches = stable/*:refs/remotes/svn/stable/*
branches = debug/*:refs/remotes/svn/debug/*

BUGSバグ

We ignore all SVN properties except svn:executable. Any unhandled properties are logged to $GIT_DIR/svn/<refname>/unhandled.logsvn：executable以外のすべてのSVNプロパティを無視します。未処理のプロパティはすべて$ GIT_DIR / svn / <refname> /unhandled.logに記録されます。

Renamed and copied directories are not detected by Git and hence not tracked when committing to SVN. I do not plan on adding support for this as it’s quite difficult and time-consuming to get working for all the possible corner cases (Git doesn’t do it, either). Committing renamed and copied files is fully supported if they’re similar enough for Git to detect them.名前変更およびコピーされたディレクトリはGitによって検出されないため、SVNへのコミット時に追跡されません。私はこれに対するサポートを追加するつもりはありません。すべての可能性のあるコーナーケースで作業することは非常に困難で時間がかかるためです（Gitもそうしません）。名前が変更されコピーされたファイルのコミットは、Gitがそれらを検出するのに十分に類似していれば、完全にサポートされています。

In SVN, it is possible (though discouraged) to commit changes to a tag (because a tag is just a directory copy, thus technically the same as a branch). When cloning an SVN repository, git svn cannot know if such a commit to a tag will happen in the future. Thus it acts conservatively and imports all SVN tags as branches, prefixing the tag name with tags/.SVNでは、（推奨されませんが）タグへの変更をコミットすることが可能です（タグは単なるディレクトリコピーであるため、技術的にはブランチと同じです）。SVNリポジトリを複製するとき、git svnはそのようなタグへのコミットが将来起こるかどうかを知ることができません。したがって、控えめに振る舞い、すべてのSVNタグをブランチとしてインポートし、タグ名の前にtags /を付けます。

CONFIGURATION設定

git svn stores [svn-remote] configuration information in the repository $GIT_DIR/config file. It is similar the core Git [remote] sections except fetch keys do not accept glob arguments; but they are instead handled by the branches and tags keys. Since some SVN repositories are oddly configured with multiple projects glob expansions such those listed below are allowed:git svnは[svn-remote]設定情報をリポジトリの$ GIT_DIR / configファイルに保存します。フェッチキーがglob引数を受け付けないことを除けば、コアのGit [remote]セクションと似ています。しかしそれらは代わりにbranchesとtagsキーによって処理されます。いくつかのSVNリポジトリは複数のプロジェクトで奇妙に設定されているので、下記のようなglob展開が許可されています。

[svn-remote "project-a"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	branches = branches/*/project-a:refs/remotes/project-a/branches/*
	branches = branches/release_*:refs/remotes/project-a/branches/release_*
	branches = branches/re*se:refs/remotes/project-a/branches/*
	tags = tags/*/project-a:refs/remotes/project-a/tags/*

Keep in mind that the * (asterisk) wildcard of the local ref (right of the :) *must* be the farthest right path component; however the remote wildcard may be anywhere as long as it’s an independent path component (surrounded by / or EOL). This type of configuration is not automatically created by init and should be manually entered with a text-editor or using git config.ローカル参照（：の右側）の*（アスタリスク）ワイルドカードは、*最も右のパスコンポーネントでなければならないことに注意してください。しかし、遠隔ワイルドカードは、それが（によって囲まれた独立したパスコンポーネントのようにどこにでもあってもよい/又はEOL）。このタイプの設定はinitによって自動的に作成されないので、テキストエディタかgit configを使って手動で入力されるべきです。

Also note that only one asterisk is allowed per word. For example:また、単語ごとにアスタリスクが1つだけ許可されていることにも注意してください。例えば：

branches = branches/re*se:refs/remotes/project-a/branches/*

will match branches release, rese, re123se, however枝が一致するリリース、RESE、re123seしかし、

branches = branches/re*s*e:refs/remotes/project-a/branches/*

will produce an error.エラーが発生します。

It is also possible to fetch a subset of branches or tags by using a comma-separated list of names within braces. For example:中かっこ内の名前のコンマ区切りリストを使用して、ブランチまたはタグのサブセットを取得することもできます。例えば：

[svn-remote "huge-project"]
	url = http://server.org/svn
	fetch = trunk/src:refs/remotes/trunk
	branches = branches/{red,green}/src:refs/remotes/project-a/branches/*
	tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/*

Multiple fetch, branches, and tags keys are supported:複数のフェッチ、ブランチ、タグのキーがサポートされています。

[svn-remote "messy-repo"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
	branches = branches/server/*:refs/remotes/project-a/branches/*
	branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
	tags = tags/server/*:refs/remotes/project-a/tags/*

Creating a branch in such a configuration requires disambiguating which location to use using the -d or --destination flag:このような設定でブランチを作成するには、-dまたは--destinationフラグを使用して使用する場所を明確にする必要があります。

$ git svn branch -d branches/server release-2-3-0

Note that git-svn keeps track of the highest revision in which a branch or tag has appeared. If the subset of branches or tags is changed after fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove (or reset) branches-maxRev and/or tags-maxRev as appropriate.git-svnはブランチやタグが現れた最も高いリビジョンを追跡します。ブランチまたはタグのサブセットがフェッチ後に変更された場合は、$ GIT_DIR / svn / .metadataを手動で編集して、適宜branches-maxRevまたはtags-maxRevを削除（またはリセット）する必要があります。

FILESファイル

$GIT_DIR/svn/*\*/.rev_map.* $ GIT_DIR / svn / * \ * /。rev_map。*

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).Subversionのリビジョン番号とGitコミット名の間のマッピング。noMetadataオプションが設定されていないリポジトリでは、これは各コミットの最後にあるgit-svn-id：行から再構築することができます（詳細については上記のsvn.noMetadataセクションを参照してください）。

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.git svn fetchとgit svn rebaseは、rev_mapが見つからないか最新でない場合に自動的に更新します。git svn resetは自動的に巻き戻します。

SEE ALSO関連項目

git-rebase[1]git-rebase [1]

GIT

Part of the git[1] suite一部のgit [1]スイート

関連記事

スポンサーリンク

SMARTY_CORE_DIR定数 Smartyのコアファイルのフルパス

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る