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?
Jocke
Re: git-svn set-tree
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
RE: git-svn set-tree
> -----Original Message----- > From: Eric Wong [mailto:normalperson@yhbt.net] > Sent: den 9 juli 2007 07:46 > To: Tjernlund > Cc: git@vger.kernel.org > Subject: Re: git-svn set-tree > > 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 have read his page, quite informative.
> > 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.
set-tree is needed for starting a SVN tree from a git tree, I don't know of any other way to do that. I got both linux and u-boot git trees in which I do custom mods. I then use git-svn to maintain a svn tree which I start with set-tree to commit the initial tree, then I dcommit my local mods.
Maybe maybe an option to git-svn init/clone where you can specify the git parent for a certain svn revision?
> > 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. >
git rebase is a bit annoying as you loose the old tree if you don't take precations. Also, I am not sure what will be committed to SVN if I rebase my local mods on top of linus latest.
Jocke
> -- > Eric Wong >