Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15

Re: git-svn-Cloning repository with complicate nesting

From: Marc Branchaud <hidden>
Date: 2016-06-15 22:47:21

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help