Re: git-svn set-tree

From: Eric Wong <normalperson@yhbt.net>
Date: Jul 9, 2007, 05:45 UTC
Message-ID: <20070709054541.GA2301@mayonaise>
In-Reply-To: <001501c7c02a$4bc130a0$0e67a8c0@Jocke>

Tjernlund <tjernlund@tjernlund.se> wrote:

Show 9 quoted lines

> 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