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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
