Re: git-svn set-tree bug

From: Eric Wong <normalperson@yhbt.net>
Date: Jun 11, 2007, 04:25 UTC
Message-ID: <20070611042509.GA19866@muzzle>
In-Reply-To: <003401c7abba$c7574300$0e67a8c0@Jocke>

Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

Show 37 quoted lines

> > -----Original Message-----
> > From: Steven Grimm [mailto:koreth@midwinter.com] 
> > Sent: den 11 juni 2007 01:37
> > To: Joakim Tjernlund
> > Cc: 'Eric Wong'; 'git'
> > Subject: Re: git-svn set-tree bug
> > 
> > Joakim Tjernlund wrote:
> > > Is there a way to tell set-tree to commit the whole "merge" branch
> > > as one svn commit?
> > > If I merge the latest kernel into my tree there will
> > > be a lot of commits that I don't want in svn.
> > >   
> > 
> > You want a "squash" merge. Something like this:
> > 
> > git checkout -b tempbranch origin/svn-branch-to-commit-merge-to
> > git merge --squash branch-with-commits-you-want-to-merge
> > git commit
> > git svn dcommit
> > 
> > The "merge" command will merge in the changes but will not commit 
> > anything; when you do the explicit "commit" command 
> > afterwards, you get 
> > the contents of the merge but from git's point of view it's just a 
> > regular commit so git-svn doesn't get confused.
> > 
> > After you do git svn dcommit, you may want to edit 
> > .git/info/grafts to 
> > tell git after the fact that this commit was a merge. It won't hurt 
> > git-svn at that point and it will mean you can do another merge later 
> > without git getting confused about what has already been merged.
> > 
> > Take a look at the script I posted a while back, which does something 
> > similar:
> > 
> > http://www.spinics.net/lists/git/msg29119.html

I must have missed this message the first time around.

> Hi Steven
> 
> That looks promising, especially Junos comment about making git-svn
> able to deal with merges. Eric, do you feel this is doable?

Doable? Yes. However, I think using grafts is quite hackish and unreliable[1]. I'd rather just have users using set-tree if they want to deal with non-linear history in the first place.

I'd personally avoid any sort of non-linear history when interacting with SVN repositories, however.

[1] - as far as I know, graft files have no verification/protection
      against corruption.  They don't get cloned, either.

-- 
Eric Wong