From: Eric Wong <normalperson@yhbt.net>
Date: Mon, 09 Jul 2007 05:45:53 GMT
Subject: Re: git-svn set-tree
Message-ID: <20070709054541.GA2301@mayonaise>
In-Reply-To: <001501c7c02a$4bc130a0$0e67a8c0@Jocke>

Tjernlund <tjernlund@tjernlund.se> wrote:
> I have noticed that if I do a git-svn set-tree, remotes/git-svn
> retains the parent from the branch where set-tree was performed.
> 
> If a coworker wants recreate my tree by using git-svn init && git-svn
> fetch he looses the parent I have in my tree.
> 
> I wonder if not git-svn set-tree can record the parent information in
> the svn repos log, so that git-svn init/fetch can recreate the parent
> relationship?

We could at yet another non-standardized property into SVN to handle
merges.  Currently there are at least two properties used in the SVN/SVK
world to represent merges (Sam Vilain can give you the fun details of
each one!).

I'm afraid adding a third incompatible yet similair property for git-svn
would just confuse people.

I've become very much against crazy stuff like set-tree which ends up
creating a M:N history mapping between git and svn.  1:1 is the simplest
and easiest.  I'm more than willing to sacrifice multi-parent histories
in git for easier compatibility with other systems.

Heck, linear history is just easier to deal with and probably preferable
in most/many cases.  I'm sure that the rising popularity of git-rebase,
quilt, stgit, guilt, mq and other like tools is a testament to that.

-- 
Eric Wong