From: Marat Radchenko <marat@slonopotamus.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, bozaro@yandex.ru, marat@slonopotamus.org
Subject: Re: [ANNOUNCE] git-as-svn: subversion frontend server for git repository
Date: Tue, 9 Sep 2014 22:57:11 +0400 [thread overview]
Message-ID: <20140909185711.GA14554@seldon> (raw)
In-Reply-To: <xmqqy4tsloxs.fsf@gitster.dls.corp.google.com>
On Tue, Sep 09, 2014 at 09:49:03AM -0700, Junio C Hamano wrote:
> Marat Radchenko <marat@slonopotamus.org> writes:
>
> > Some time ago I complained [1] about troubles using Git
> > on a project with high ratio of non-programmers.
> > ...
> > Then, a lost'n'forgotten git_svn_server [4] was found.
> > ...
>
> Interesting.
Actually, no. As I said, git_svn_server made several ineffective
architectural choices. It can be viewed as a proof-of-concept work though.
> > Current limitations:
> > ...
> > * 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).
Thus, we only expose "main" history line to SVN where "main" means
"reachable through first-parent traversal from branch tip".
To keep SVN history consistent, commits that once became visible to SVN
have to remain visible. This limitation will be removed when git-as-svn
gets persistent storage and will be able to remember what *was* main line.
Imagine you had following history:
--- time --->
A -- B -- C
Now you merge (via Git) a feature branch:
A -- B -- C -- G
\ /
D -- E --- F
For SVN, history will look this way:
A -- B -- C -- F
We might introduce merge-info support for this one day.
And now the *bad* case. You have the same initial history but do *inverted merge*:
A -- D -- E -- F -- G'
\ /
B -- C ---------/
^
|
Previous branch tip
That's where things brake because for SVN, history transforms from
A -- B -- C
to
A -- D -- E -- F -- G'
And all users who checked out revisions B & C get their working copies screwed.
This also means that push --force also must not be performed.
Quoting my initial post [1] about inverted merges (you might call them
"merges with swapped parents").
> I call it "swapped/reverse merge problem".
>
> In short:
> 1. Hack, hack, hack
> 2. Commit
> 3. Push, woops, reject (non-ff)
> 4. Pull
> 5. Push
>
> The root of evil is step #4 that creates a merge commit with "swapped" parents -
> local commits become first parent, remote commits become second. If one would want to
> make proper parent order, he would have to: 1. git fetch
> 2. git checkout origin/master -b tmp
> 3. git merge master
> 4. git push
> 5. git checkout master
> 6. git merge origin/master
> 7. git branch -d tmp
>
> And all this branch dance produces exactly the same commit (content-wise) as simple
> "pull, push" sequence with the only difference in parent order. And things become
> even worse if comeone pushes more commits to remote repo while you perform this
> dance.
>
> We can't expect all developers (especially, designers and artist) to do it. They
> don't want to use branches and just work on mainline. This is especially important on
> early development stages when new features (that designers' work depends upon) are
> added every day.
>
> Additionally, many git-related tools depend on first-parent convention and show wrong
> graphs/diffs.
[1] http://marc.info/?l=git&m=139866660018802
next prev parent reply other threads:[~2014-09-09 18:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 11:19 [ANNOUNCE] git-as-svn: subversion frontend server for git repository Marat Radchenko
2014-09-09 16:49 ` Junio C Hamano
2014-09-09 18:57 ` Marat Radchenko [this message]
2014-09-09 19:30 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140909185711.GA14554@seldon \
--to=marat@slonopotamus.org \
--cc=bozaro@yandex.ru \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).