[PATCH v3 4/4] git-svn: Note about tags.
Document that 'git svn' will import SVN tags as branches. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 021fb0e..445b033 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -968,6 +968,12 @@ 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. +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/'. + CONFIGURATION - -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] git-svn: Expand documentation for --follow-parent
Describe what the option --follow-parent does, and what happens if it is set or unset. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index d8e5082..021fb0e 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -628,10 +628,19 @@ ADVANCED OPTIONS Default: "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, or if we - started tracking a branch and never tracked the trunk it was - descended from. This feature is enabled by default, use + 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. + [verse] -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] git-svn: Recommend use of structure options.
Document that when using git svn, one should usually either use the directory structure options to import branches as branches, or only import one subdirectory. The default behaviour of cloning all branches and tags as subdirectories in the working copy is usually not what the user wants. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 55bed53..d8e5082 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -739,7 +739,8 @@ for rewriteRoot and rewriteUUID which can be used together. BASIC EXAMPLES -- -Tracking and contributing to the trunk of a Subversion-managed project: +Tracking and contributing to the trunk of a Subversion-managed project +(ignoring tags and branches): # Clone a repo (like git clone): @@ -764,8 +765,10 @@ Tracking and contributing to an entire Subversion-managed project (complete with a trunk, tags and branches): -# Clone a repo (like git clone): - git svn clone http://svn.example.com/project -T trunk -b branches -t tags +# Clone a repo with standard SVN directory layout (like git clone): + git svn clone http://svn.example.com/project --stdlayout +# Or, if the repo uses a non-standard directory layout: + git svn clone http://svn.example.com/project -T tr -b branch -t tag # View all branches and tags you have cloned: git branch -r # Create a new branch in SVN @@ -918,6 +921,21 @@ 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. +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. + 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, -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] git-svn: More docs for branch handling
Updated version of my documentation patch for git-svn. Thanks to Junio C Hamano for pointing out improvements. Sebastian Leske (4): git-svn: Document branches with at-sign(@). git-svn: Recommend use of structure options. git-svn: Expand documentation for --follow-parent git-svn: Note about tags. Documentation/git-svn.txt | 92 ++--- 1 file changed, 86 insertions(+), 6 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] git-svn: Document branches with at-sign(@).
git svn sometimes creates branches with an at-sign in the name (branchname@revision). These branches confuse many users and it is a FAQ why they are created. Document when git svn creates them. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 47 + 1 file changed, 47 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 8b0d3ad..55bed53 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -830,6 +830,53 @@ 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). +HANDLING OF SVN BRANCHES + +If 'git svn' is configured to fetch branches (and --follow-branches +is in effect), it will sometimes create multiple git branches for one +SVN branch, where the addtional 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. + +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 (copied) 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: "). + +Additionally, it will create a special branch named +'@', where 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 '@'. + +Note that this may mean that multiple git commits are created for a +single SVN revision. + +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/). + CAVEATS --- -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] git-svn: Note about tags.
Document that 'git svn' will import SVN tags as branches. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt |7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 6bda014..18d5e45 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -959,6 +959,13 @@ 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. +SVN tags (if tracked using options '--tags' or '--stdlayout') are +imported as git branches, prefixing the tag name with 'tags/'. +This is because tags in SVN behave more like git branches: The contents +of a tag need not be identical to the tagged commit, and 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). + CONFIGURATION - -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] git-svn: Expand documentation for --follow-parent
Describe what the option --follow-parent does, and what happens if it is set or unset. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index bfa8788..6bda014 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -628,10 +628,19 @@ ADVANCED OPTIONS Default: "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 (i.e. branched) 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, or if we - started tracking a branch and never tracked the trunk it was - descended from. This feature is enabled by default, use + 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 where 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. + [verse] -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] Recommend use of structure options for git svn.
Document that when using git svn, one should usually either use the directory structure options to import branches as branches, or only import one subdirectory. The default behaviour of cloning all branches and tags as subdirectories in the working copy is usually not what the user wants. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 824bf82..bfa8788 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -739,7 +739,8 @@ for rewriteRoot and rewriteUUID which can be used together. BASIC EXAMPLES -- -Tracking and contributing to the trunk of a Subversion-managed project: +Tracking and contributing to the trunk of a Subversion-managed project +(ignoring tags and branches): # Clone a repo (like git clone): @@ -764,8 +765,10 @@ Tracking and contributing to an entire Subversion-managed project (complete with a trunk, tags and branches): -# Clone a repo (like git clone): - git svn clone http://svn.example.com/project -T trunk -b branches -t tags +# Clone a repo with standard SVN directory layout (like git clone): + git svn clone http://svn.example.com/project --stdlayout +# Or, if the repo uses a non-standard directory layout: + git svn clone http://svn.example.com/project -T tr -b branch -t tag # View all branches and tags you have cloned: git branch -r # Create a new branch in SVN @@ -871,6 +874,21 @@ 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. +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 +folders 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. + 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, -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] git-svn: Document branches with at-sign(@).
git svn will sometimes create branches with an at-sign in the name (branchname@revision). These branches confuse many users and it is a FAQ why they are created. Document when git svn will create them. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 38 ++ 1 file changed, 38 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 8b0d3ad..824bf82 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -881,6 +881,44 @@ different name spaces. For example: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* +If 'git svn' is configured to fetch branches (and --follow-branches +is in effect), it will sometimes create multiple branches for one SVN +branch, where the addtional 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. 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 (copied) 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: "). +Additionally, it will create a special branch named +'@', where 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 '@'. +Note that this may mean that multiple git commits are created for a +single SVN revision. 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/). + BUGS -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] git-svn: More docs for branch handling in
Updated version of my documentation patch for git-svn. Thanks to Michael J Gruber and Eric Wong for helpful comments. Sebastian Leske (4): git-svn: Document branches with at-sign(@). Recommend use of structure options for git svn. git-svn: Expand documentation for --follow-parent git-svn: Note about tags. Documentation/git-svn.txt | 84 + 1 file changed, 78 insertions(+), 6 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-svn: What is --follow-parent / --no-follow-parent for?
Hi Steven, hi Eric, thanks for your explanations. I'll try to update my doc patch to include them. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multiple threads of compression
Hi, [Thorsten Glaser , 2012-11-25 17:27]: > On a multi-core machine, the garbage collection of git, as well > as pack compression on the server side when someone clones a > repository remotely, the compression is normally done automatically > using multiple threads of execution. > > That may be fine for your typical setups, but in my cases, I have > two scenarios where it isn’t: > > ⓐ The machine where I want it to use only, say, 2 of my 4 or 8 cores > as I’m also running some VMs on the box which eat up a lot of CPU > and which I don’t want to slow down. > ⓑ The server VM which has been given 2 or 3 VCPUs to cope with all > the load done by clients, but which is RAM-constrained to only > 512 or, when lucky, 768 MiB. It previously served only http/https > and *yuk* Subversion, but now, git comes into the play, and I’ve > seen the one server box I think about go down *HARD* because git > ate up all RAM *and* swap when someone wanted to update their clone > of a repository after someone else committed… well, an ~100 MiB large > binary file they shouldn’t. unfortunately I can't really speak to the git side of things, but both of these cases just sound like standard resource starvation. So why don't you address them using the usual OS mechanisms? If you want to prevent git from sucking up CPU, nice(1) it, and if it eats too much RAM, use the parent shell's ulimit mechanism. Granted, this might also require some changes to git, but wouldn't that be a simpler and more general approach to solving starvation problems? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] Recommend use of structure options for git svn.
Document that when using git svn, one should usually either use the directory structure options to import branches as branches, or only import one subdirectory. The default behaviour of cloning all branches and tags as subdirectories in the working copy is usually not what the user wants. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 482d60d..928a961 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -871,6 +871,16 @@ 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. +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 +folders in the working copy. For projects with many branches this will +lead to a working copy many times larger than just the trunk. It is +recommended to either use the the options for trunk / tag / branch +directory, or to only clone the trunk (or a subdirectory of the +trunk). + 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, -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] git-svn: Expand documentation for --follow-parent
Describe what the option --follow-parent does, and what happens if it is set or unset. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 928a961..92780ef 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -628,11 +628,19 @@ ADVANCED OPTIONS Default: "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 (i.e. branched) 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, or if we - started tracking a branch and never tracked the trunk it was - descended from. This feature is enabled by default, use - --no-follow-parent to disable it. + that has been moved around within the repository (note that you + must track both the old and the new name for the whole history + to be imported). If this feature is disabled, the branches + created by 'git svn' will all be linaear and not share any + history, meaning that there will be no information on where + branches where branched off or merged. This feature is enabled + by default, use --no-follow-parent to disable it. + [verse] config key: svn.followparent -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] git-svn: Document branches with at-sign(@).
git svn will sometimes create branches with an at-sign in the name (branchname@revision). These branches confuse many users and it is a FAQ why they are created. Document when git svn will create them. Signed-off-by: Sebastian Leske --- I found various important features of git-svn that are not documented. Thus I created a series of patches to add and update documentation for git-svn. I am sending this as four patches (of which this mail is the first). I have tried my best to make the patches ready for inclusion into git, but if there's any feedback, I'll gladly incorporate it. Documentation/git-svn.txt | 26 ++ 1 file changed, 26 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 8b0d3ad..482d60d 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -881,6 +881,32 @@ different name spaces. For example: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* +If 'git svn' is configured to fetch branches (and --follow-branches +is in effect), it will sometimes create multiple branches for one SVN +branch, where the addtional 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 the branch, to connect the branch to the history of the +other branches. Normally, 'git svn' will find the git commit that +corresponds to the SVN revision a branch was created (copied) from and +use that as the parent. 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' (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 the branch will not be connected to the history of the other +branches. 'git svn' will also create a commit from the SVN revision the +branch was copied from, and use that as the parent commit of the branch +(this is indicated by the message "Initializing parent: "). +Additionally, it will create a special branch named +'@', where is the SVN revision +number the branch was copied from. This branch will point to the +specially created parent commit. +If in SVN the branch was deleted and later recreated from a different +version, there will be multiple such branches with an '@'. + BUGS -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] git-svn: Note about tags.
Document that 'git svn' will import SVN tags as branches. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 92780ef..6212b24 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -938,6 +938,12 @@ 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. +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/'. + CONFIGURATION - -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git bash does not access drive f:
On 2012-11-22, Angelo Borsotti wrote: > Hi > > I have attached an external disc, which appears on Windows as drive f: > in Windows Explorer. > Right-clicking on it displays a context menu showing (among other > items) Git Init Here, Git Gui and > Git Bash. The first two work properly on that drive. > However, the git bash does not. Not even the one that is run from the icon: > > $ cd f: > sh.exe": cd: f:: No such file or directory This is probably a known limitation of MSYS (the shell environment that Git Bash uses, which is part of MingW): Drive letters added after MSYS has started only become visible if all MSYS processes are stopped and restarted. See e.g. How to register newly mounted drive in git bash? http://stackoverflow.com/questions/5197540/ for some more details. It seems there is no easy workaround, so you'll need to close all Git Bash windows and reopen them. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-svn: What is --follow-parent / --no-follow-parent for?
Hi, on reading the docs of "git-svn", I stumbled across this paragraph: > --follow-parent > This is especially helpful when we’re tracking a directory that has been > moved around within the repository, or if we started tracking a branch > and never tracked the trunk it was descended from. This feature is > enabled by default, use --no-follow-parent to disable it. However, this does not make sense to me: This sounds like there is no good reason *not* to enable this option. So why is it there? And in what situation might I want to use "--no-follow-parent"? As a matter of fact, I'm not even sure what "--no-follow-parent" does (and the docs don't really say). I tried it out with a small test repo with a single branch (produced by copying the trunk, then later deleted). With --follow-parent git-svn correctly detected the branch point, and modeled the branch deletion as a merge. With --no-follow-parent it just acted as if branch and trunk were completely unrelated. Commit graph of git-svn result: --follow-parent: --no-follow-parent: | | /| | | / | | | | | | | | | | | | | | | \ | | | \| | | | | (please excuse cheap ASCII art) Is that the only effect of --no-follow-parent? And again, why would I want that? I'd be grateful for any clarifications. If I manage to understand the explanation, I'll volunteer to summarize it into doc patch (if there are no objections). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
