From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 09 Sep 2014 19:30:23 GMT
Subject: Re: [ANNOUNCE] git-as-svn: subversion frontend server for git repository
Message-ID: <xmqqiokwk2wg.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140909185711.GA14554@seldon>

Marat Radchenko <marat@slonopotamus.org> writes:

>> >   * You must not do 'inverted merges'. Old HEAD must be reachable from
>> >     new HEAD by first-parent traversal.
>> 
>> I am not sure what you mean by this to properly assess how
>> significant this limitation is.  Care to draw a simple picture?
>
> SVN doesn't support nonlinear history (except merge-info crutch).
> ...
> And now the *bad* case. You have the same initial history but do *inverted merge*:

That is a bad way to answer a question that asks "what do you mean
by an 'inverted merge', which is not in our normal lexicon?" ;-)

	You must not merge the current tip of SVN server *into* the
	work you did on top of a past state you obtained from the
	SVN server.  Check out the current state from the SVN side,
	and merge your work into it instead.

or something like that is what people would understand without
introducing a new/unused word to the world.  And

> A -- D -- E -- F -- G'
>  \                 /
>   B -- C ---------/
>        ^
>        |
>     Previous branch tip

this illustrates the topology you meant reasonably well, especially
if you marked D, E and F as "your own work" (as opposed to what the
server side did in the meantime while you worked, i.e. B and C).

Thanks for a clarification.