> After reading a lengthy discussion on the list, I've come to the
quoted text
> conclusion that creating a 'remotes' directory in refs isn't
> such a bad idea.
>
> You can still branch from it by specifying remotes/git-svn (not
> needing the leading 'refs/'), and the documentation has been
> updated to reflect that.

i got stuck in that.

git-svn does the remotes/svn-git reference good, git pull hasn't
recognized it, yet. So i had to do a symlink from .git/refs/remotes to
.git/refs/heads/ to do the git pull...

then i got a bit stuck because of conflicts.... which i resolved (thank god).

the third thing is that the git-svn commit command does deletions of
certain files very often, when i commit some patches i pulled into my
private-talk-to-svn-branch. in on of the next commits the same files are
added again.. but i thought "o my god, i am screwed", when i saw the
scheduled deletions the first time... that is a bit confusing for the
users.

so in conclusion, i think, you should teach git pull to recognize
refs/remotes as heads to be pulled from (not to be pulled at)...

btw, i like the visualization of the remotes-refs in gitk.

Nicolas

-
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