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

[Eric Wong <normalperson@yhbt.net>]

Peter Baumann <waste.manager@gmx.de> wrote:
> On Thu, Aug 16, 2007 at 01:21:10AM -0700, Eric Wong wrote:
> > Peter Baumann <waste.manager@gmx.de> wrote:
> > > On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:
> > > > Hi there,
> > > >
> > > > when running "git-svn dcommit" git-svn tries to find the svn-URL of the 
> > > > current branch int git by looking for the most recent git log-entry 
> > > > corresponding to a commit in svn (see working_head_info in git-svn).  In 
> > > > case a merge just happended this might be the URL of another branch. Would 
> > > > using "log --first-parent" instead of a plain "log" take care of this 
> > > > problem or would it have other undesirable consequences?
> > > >
> > > 
> > > I had this situation, too.
> > > 
> > > 
> > > 			a = svn branch 'a'
> > >         m		b = svn branch 'b' (in my case, it was trunk)
> > >       /   \		m = a merge of branch 'a' and 'b', not yet commited to svn
> > >      a     b
> > > 
> > > So trying to dcommit m, git svn can't figure out on which branch, as 'a'
> > > and 'b' are both reachable. I had to use a graft file to lose one of the
> > > parents, which let git-svn commit to SVN.
> > > 
> > > So for a short fix to get the work done, you could create a graft file
> > > where you fake m to only have one parent.
> > 
> > Ok.  I'm regretting making 733a65aa5d33196fac708ebd12a98a1060cbf3c2 now.
> > 
> > It doesn't introduce the problem, but it does encourage it.  I still
> > happen to believe allowing git-merges in repositories that try to
> > interoperate with SVN is just giving rope for users to hang themselves
> > with.
> > 
> > 
> > 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?
> 
> By removing merges in git-svn, it would lose much of its 'magic'. I have
> to mainain a SVN branch and from time to time, I merge with trunk. So
> it'll totally screw me if I lose the merge history (sure, I could use
> a graft file, but a real merge is preferable, because I can clone the
> repo then).

Ok, outright refusing to merge/pull is probably too much.  But spewing
a big warning may help.

> > 13c823fb520eaf1cded520213cf0ae4c3268208d was introduced to allow using
> > git-format-patch + git-am to apply patches from other branches in SVN,
> > which is the recommended way to do "merging" with git-svn.
> > 
> Hm. What about cherry pick? I ask because a friend of mine messed up the
> SVN repo after cherry picking a commit from 'trunk' and then his next
> dcommit put everything into 'trunk' instead of his own branch (hopefully,
> I remembered correctly; but at least I know for sure a cherry pick from
> trunk was involved). I can't ask him right now, because he is on
> vacation till monday, but I'll Cc him, just in case.

Yeah, cherry-pick works, too.  I've never actually used cherry-pick
myself, because git-format-patch and git-am let me work on a series of
patches rather than one-at-a-time.

-- 
Eric Wong