Re: git-svn set-tree bug

Eric Wong wrote:

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.

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