On 2007-10-16 00:58:27 -0700, Eric Wong wrote:
> If we support .gitignore <-> svn:ignore in git-svn; bidirectional,
> transparent mapping is the only way I want to go.
Fair enough.
> This means that *all* .gitignore files will be translated to
> svn:ignore files and vice versa; and the .gitignore files will be
> NOT be committed to SVN itself, but present in the git-svn created
> mirrors.
OK.
> Recursive .gitignore definitions will be mapped to svn:ignore
> recursively on the client side; and non-recursive ones will only map
> to one directory.
>
> Sound good?
>
> I may be sleepy at the moment, but the thought of implementing this
> is sounding complicated now...
I think this is a mistake. If a user adds *.foo to the top-level
.gitignore, this will add *.foo to svn:ignore of _every_ directory in
the whole tree. And coming up with semantics that are sane for e.g.
git -> svn -> git roundtrips seems difficult.
It would be better and far simpler to either
1. Move the contents of svn:ignore and .gitignore back and forth
untouched, disregarding the slight semantic mismatch.
git-svnignore does this (albeit only in one direction), and it
works surprisingly well in my experience.
2. Do as in (1), but call the file .svnignore instead of .gitignore.
And have a git-svn command that translates all the .svnignore
files in the tree to corresponding .gitignore files.
> One goal of git-svn is that other users shouldn't be able to tell if
> a user is using git-svn or plain svn; even.
Agreed.
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
-
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
