Re: Regression: git-svn clone failure

From: Andrew Myrick <amyrick@apple.com>
Date: Dec 22, 2009, 23:50 UTC
Message-ID: <B39991E2-D632-4FD5-B5DA-0B6B502BBFC8@apple.com>
In-Reply-To: <1261516416.23944.44.camel@denix>

On Dec 22, 2009, at 1:13 PM, Sam Vilain wrote:

Show 17 quoted lines

> On Tue, 2009-12-22 at 11:38 -0800, Andrew Myrick wrote:
>> Worked like a charm; the fetch is proceeding now.  Thanks, Eric!
>> 
>> Do you know what the "svn cherry-pick ignored" warnings mean, and if it's
>> something I should be concerned about?  This particular project is missing
>> up to 65 commits at some revisions.
> 
> With git, merge parent relationships imply (conceptually, anyway) that
> all of the changes reachable from that branch are included in the
> commit.  If someone is doing cherry-picking, then they are specifically
> excluding some commits, so adding a merge parent to that branch isn't
> right.  This is what the warning is saying.  It's happening every commit
> because that section of code doesn't know whether a mergeinfo record is
> new or not.
> 
> This wasn't happening with the old code, because it was simply not
> detecting them correctly and adding merge parents anyway.

This makes perfect sense now.  Thank you for clarifying.  Unfortunately, I don't think the patch you provided will help my particular problem.  Allow me to elaborate.

As I mentioned before, my project's integration model is to create a separate branch for every change.  Specifically, we create a branch from a recent internal tag.  So, the model for a simple bug fix looks something like this:

            F---G  branch1
          /           \
        D  tag1  \    E  tag2
       /                 \  /
A---B                 C  trunk

Revision B on trunk was tagged with tag1.  A bug was found in that version, so a branch was created from tag1, a fix was committed to the branch, and then the branch was merged back to trunk.  Finally, trunk is tagged with tag2.

The "missing commit" messages show up when git svn fetch is fetching revision C.  It warns the there is a cherry-pick from branch1, and states that commits D and F are missing.  These commits are just copies, however; there is no code change.  The svn:mergeinfo property on trunk also only points at commit G.  Should git-svn be ignoring commits D and F, which are copy operations, not code changes?

Also of note is that we very, very rarely cherry-pick commits, and never directly from a branch to trunk.  Branches are always integrated back to trunk in their entirety.

-Andrew