I just spotted this question about recovering from a clone done without --stdlayout. I didn't find documentation of this flag - what does it do?
-
The documentation is here: http://www.kernel.org/pub/software/scm/git/docs/git-svn.html#_commands – Mark Longair Mar 19 '11 at 10:40
-
1@Mark - in my defense, the answers here are much clearer than the documentation. – ripper234 Mar 19 '11 at 10:43
-
3right, I think S.O. is a nice counterpart to the git man pages in many ways :) The man pages are accurate and tell you what you need to know, but it takes quite a bit of knowledge about git to be able to understand what they say. – Mark Longair Mar 19 '11 at 10:48
2 Answers
Subversion doesn't have any concept of branch or tag. Instead, those are typically simulated by simply copying the contents of the repository into a directory.
In order for git svn
to be able to recognize branches and tags and the main branch ("trunk"), you have to explicitly tell it where to find them, using the --tags
(or -t
), --branches
(or -b
) and --trunk
(or -T
) options.
However, many Subversion repositories follow a standard convention, laid out in the Subversion book, of --trunk=/trunk --branches=/branches --tags=/tags
. --stdlayout
(or -s
) encodes this convention, so that you don't have to pass the same arguments every time you clone a Subversion repository.
You can find this information in the git-svn(1)
manual page, which you can access under Unix with man git-svn
and in an operating system independent fashion via the builtin Git help system with git help svn
. All of the Git man pages are also available on Kernel.Org and they are usually the first search result when you search for git-svn(1)
.

- 363,080
- 75
- 446
- 653
-
2Actually, for `stdlayout` matching, the arguments are `--trunk=trunk --branches=branches --tags=tags` (without the leading `/`) – rotoglup Aug 18 '12 at 08:45
-
-
4@BitLegacy01: I wrote that answer 4.5 years ago, and at that time, Subversion didn't have a concept of *branches* or *tags*, instead you would just copy the contents of the repository and either not change it (in which case the copy would behave just like a tag, and typically be located in a directory named `tags`) or continue to change it (in which case the copy would behave just like a branch and typically be located in a directory named `branches`). The mainline development would typically happen in a subdirectory called `trunk`. I haven't looked at Subversion in over 4 years, so, it may … – Jörg W Mittag Dec 02 '15 at 13:33
-
3… very well be that this has changed. Feel free to update the answer if that is the case. Do you happen to know why the Subversion developers felt the need to complicate their beautifully elegant object model with such an unnecessary complication? I always found the freedom and flexibility that *not* hardcoding the behavior of tags and branches into the object model gave me one of the major strengths of Subversion. I built some fairly complex repository structures that would simply have been impossible with hardcoded tags and branches. – Jörg W Mittag Dec 02 '15 at 13:36
--stdlayout
(-s
) tells git-svn
that folders in /branches
should be imported as branches, and that folders in /tags
are snapshots of a project state and should be imported as tags. The master branch will be set to /trunk
.
It's equivalent to --trunk=trunk --tags=tags --branches=branches

- 3,683
- 4
- 33
- 41

- 246,190
- 53
- 318
- 364