From: "Joakim Tjernlund" <joakim.tjernlund@transmode.se>
To: "'Eric Wong'" <normalperson@yhbt.net>
Cc: <git@vger.kernel.org>
Subject: RE: git-svn set-tree
Date: Wed, 11 Jul 2007 00:45:53 +0200 [thread overview]
Message-ID: <000901c7c344$12b431a0$02ac10ac@Jocke> (raw)
In-Reply-To: <20070709054541.GA2301@mayonaise>
> -----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
>
prev parent reply other threads:[~2007-07-10 22:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-07 0:03 git-svn set-tree Tjernlund
2007-07-09 5:45 ` Eric Wong
2007-07-10 22:45 ` Joakim Tjernlund [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000901c7c344$12b431a0$02ac10ac@Jocke' \
--to=joakim.tjernlund@transmode.se \
--cc=git@vger.kernel.org \
--cc=normalperson@yhbt.net \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox