Re: git-svn set-tree bug

Joakim Tjernlund [off-list ref] wrote:

quoted

-----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:

quoted

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