Jonathan Nieder writes:
> Sverre Rabbelier wrote:
> > 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
--
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