Daniele Segato wrote: > > hum... > It could be an idea but I don't know how hard could it be to check it: > how much deep inside the tree should Git search for branch? Well, as far as it takes. Actually, the search should be fairly well constrained. After checking that the entries under a particular path aren't a copy of the trunk, each entry can only represent either a branch that git-svn already knows about, or a new branch. > what if there are branches that are completely differents? Not sure what you mean there. Can you come up with an example of this? > may be the user could create and pass a "branch model" to git svn to > make it able to decide what is a branch and what isn't. > > I think there are many options > > In my case It would have worked defining a structure like: > BRANCHES/*/root -> remote/svn/branch/* > BRANCHES/*/*/root -> remote/svn/branch/*/* > > But it would be better with something like: > BRANCHES/\([^\/]+\)/root -> remote/svn/branch/$1 > BRANCHES/\([^\/]+\)/\([^\/]+\)/root -> remote/svn/branch/$1/$2 > > like a grouped regex. > > every branch not matching the regex will be skipped.. > only an idea.. It couln't work in every situation but it would allow a > greater degree of freedom in the configuration. Turning the branch refspecs into true regular expressions sounds like a good idea to me, and would probably be easier to implement than the trunk-detection stuff I proposed. Though there'd have to be a way to stay compatible with or upgrade the current non-regex refspecs. > I don't know if Git developers are interested in thinking on some > features like this.. it sound like an SVN-only hack to me. All of git-svn is already a hack for dealing with SVN. :) I'm sure a patch for this would be welcome. M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html