Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)

Jonathan Nieder writes:

Sverre Rabbelier wrote:

quoted

I'm thinking we can just refuse to let through a commit that is
non-linear, as if there's a hook on the server side that rejects such
a history. Since we're representing the svn remote as a regular
remote, the user can just do 'git rebase @{u}" themselves if they end
up with a non-linear history.

Sounds good to me!

Ofcourse. I can't think of a sane way to deal with commits that aren't
based on upstream. We can't expect the user to rewrite the history,
push and expect it to work. I'm only looking at perfect two-way
mapping for a restricted set of operations on the Git-side.

FWIW I just wanted to make sure people don't forget about the
incompatible object models.  The pretend-upstream-has-a-vicious-update-hook
approach sounds like a sane way to deal with this for pushing from
git to svn (like (III) but making the user do more of the work).

Pulling from svn is a harder problem but luckily the single-upstream
case is the usual case (so object model mismatches are easier to cope
with as long as one can find the corresponding svn rev number for a
given git object easily).

Yeah, I'm only looking at single-upstream SVN with stable revision
numbers, timestamps etc.

-- Ram