Re: git-svn: Finding the svn-URL of the current branch in git

From: Eric Wong <normalperson@yhbt.net>
Date: Aug 18, 2007, 09:09 UTC
Message-ID: <20070818090913.GA13936@soma>
In-Reply-To: <7vir7eh7mc.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> Eric Wong <normalperson@yhbt.net> writes:
> 
> > Junio:
> > Would you object to having git-merge spew a big fat warning
> > and/or outright refuse to let git-merge run on git-svn repositories?
> 
> Actually I do.  A major, if not primary, selling point of
> git-svn has been that svn cannot do merges but if you import to
> git you can, and I've had an impression that Sam's git-svn intro
> alludes to this capability as well.

Wow. My primary reasons for git-svn are completely different: speed and offline usability; and merging was not so much a concern for me.

I've grown to prefer the patch + rebase model of keeping history linear in my work. This is different than from when I first picked up git: went overboard on merging just to see what kind of interesting graphs I could create in gitk :)

So I didn't always prefer the recommended way git-svn works now. In the beginning there was the "git-svn commit" command, which has now been named "set-tree". I haven't used set-tree in ages, but I think it still supports preserving history of a git <-> git merging after commiting to SVN. The problem with set-tree was that it would either:

a) make history ugly (with duplicate commits) for git users, as history
   never gets rewritten when using set-tree.

or

b) hide history from SVN users.

Show 8 quoted lines

> If I understand you correctly, your position is that the svn
> side has the authoritative history when using git-svn, and we
> should refuse to do anything on the git side that the resulting
> history in svn cannot represent.  I know and respect that you
> have thought about the issues involved long enough before that
> declaration of defeat, but at the same time, I would really hope
> that we can come up with a workable compromise to allow merge
> tracking on the git side.

Yes. From what I gather, developers only use git-svn because they don't have enough swing within their group to replace SVN. I don't think encouraging git-svn users to isolate themselves with their own history and propagating less-useful history to the non-SVN users in a project is a good thing.

Show 7 quoted lines

> It probably does not even have to interoperate with people who
> do their own merge tracking using svk.  Perhaps something as
> simple and ugly as recording the parent commit object names on
> the git side as a trailer to the commit log message we push back
> to svn would allow people who interact with the same svn
> repository from their own git-svn managed git repository to
> interoperate with each other?

Of course, git-svn has gotten a lot more users than I expected it would, so maybe I'll implement it and see where it takes us.

This could just be as simple as using the code for set-tree and instead using it to create revprops in SVN. I'd probably be inventing a fourth method of doing merge-tracking in SVN, though...

-- 
Eric Wong