Subject: Re: git-svn set-tree bug

From: Steven Grimm <[email-masked]>
Date: Tue, 12 Jun 2007 05:15:12 -0700

Eric Wong wrote:
> Yes, "mainline" meaning the history that would be committed to SVN if
> history were linear.
>   

I think the first parent is always the right one to follow. The only 
time you won't hit a git-svn revision is if the user is trying to commit 
a branch that is not originally derived from a git-svn branch, and IMO 
that's something that git-svn is perfectly justified in refusing to do. 
Also, the default "git log" output will follow the first parent; users 
who run that are going to have a natural expectation that the subsequent 
commits will be merged into the most recent git-svn revision as shown by 
that tool.

> This only works if a merge is the first commit to be committed
> in a chain of commits.
>   

As for the more complex case of a chain of commits with a merge in the 
middle, IMO walking along the chain of first parents until you hit a 
git-svn revision, then proceeding forward in time from there rewriting 
parents as you've described, is always going to be the right thing to 
do. Or at least, all the use cases I can think of seem to be correctly 
covered by that approach. Can someone come up with counterexamples?

This is great -- I'm looking forward to ditching my hackish merge script!

At the risk of getting ahead of myself, here's one more thought: in the 
case where a merge's parents are all git-svn revisions -- that is, where 
the user is using git to merge svn branches -- I wonder if it makes 
sense to optionally record that merge somehow in the commit comment on 
the svn side. I think that could be made relatively human-readable so as 
not to be too obnoxious for people browsing the svn history. That way 
someone pulling down a fresh git-svn clone of the svn repo could get a 
nice clean history with the merges represented properly in the git 
revision history.

That's justifiable in another way too: the autogenerated comments on git 
merge commits won't really make much sense over on the svn side, where 
merges are thought of in terms of revision ranges. So replacing the 
git-specific merge message with an svn-specific one doesn't seem 
unreasonable to me. (Again, optionally.) And in cases where the user has 
supplied his own merge comment on the git side, annotating it with the 
additional git-svn metadata seems reasonable to me. We are already fine 
with the git-side comments having a line of git-svn metadata, after all.

Most of the svn-side merge comments in my company's repo look like 
either "svn merge -r12345:67890 mybranch" (where the developer wants to 
make the merge's inputs very explicit to avoid any confusion) or "Merge 
revisions 12345 through 67890 from mybranch", occasionally surrounded by 
some explanatory text. If git-svn replaced the canned git merge message 
with a canned message like one of those, people wouldn't be able to tell 
I'd used git-svn instead of svn to do the merge.

-Steve