On 2007-10-16 00:58:27 -0700, Eric Wong wrote:

quoted text
> If we support .gitignore <-> svn:ignore in git-svn; bidirectional,
> transparent mapping is the only way I want to go.

Fair enough.

quoted text
> 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.

quoted text
> 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.

quoted text
> 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@treskal.com
      www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html