OK, I think this captures it (branches replaced with real names so the  
images below make sense)


1---2---3---4---5---6---7---8---9  <- trunk
      \           \
       \           \-a---c---c---d  <- GLIFFY_ONLINE_REST_API (where  
I'm working)
        \
         \-I                        <- GLIFFY_ONLINE_SSO, no commits,  
just a branch in SVN

[ I is branched off of 2 and a is branched off of 5 ]

Changes at 3 and 4 show up as conflicts when I merge  
GLIFFY_ONLINE_REST_API and trunk

The situation you describe could be it.  It's hard to tell from gitk  
just what is going on.

In gitk, when I find the commit in SVN that created  
GLIFFY_ONLINE_REST_API, I see this:

http://www.naildrivin5.com/images/git_top.jpg  (The commit message i  
"Rest API Branch" and "GLIFFY_WEBSITE_MAR" is NOT the name in SVN)

When I find where that yellow arrow goes, I see this:

http://www.naildrivin5.com/images/git_bottom.jpg

I will look into the graft solution....

Dave

On Jun 9, 2008, at 4:53 PM, Jakub Narebski wrote:

quoted text
> davetron5000 <davetron5000@gmail.com> writes:
>
>>>
>>> You can ask git to find branch point using "git merge-base trunk  
>>> FOO",
>>> which should return 'c' (actually, sha-1 of this commit).
>>
>> OK, this revealed interesting results.  The commit it gave me was a
>> commit right before ANOTHER SVN branch that I was originally to work
>> on, but never did.  The files git-merge showed conflicts for were
>> files modified since THAT branch (call it BAR) was created and before
>> my branch (FOO) was created.
>
> Could you write some ascii-art diagram showing the situation? It is
> hard to grasp the situation fully only from above description.
>
>> So, any ideas why git thinks that my two branches are rooted at BAR
>> and not FOO?  git-svn dcommit on local-FOO commits to FOO and not  
>> BAR.
>
> Note that the situation described below might be not related to your
> problem; please view history carefully using some (graphical) history
> browser like gitk.
>
> It could happen that commits which should be identical aren't,
> e.g. because of different timestamp, or different author, or lack of
> svn-id: line, or something like that.  This isn't helped by the fact
> that Subversion doesn't store information about merges; and even if it
> does (SVK or svnmerge extensions) I'm not sure if git-svn can use it.
>
> So the situation might be like following:
>
>   1---2---3---4---A---B---C   <-- branch 1
>
>   1'--2'--3'--4'--a---b---c   <-- branch 2
>
> while you want it to be
>
>   1---2---3---4---A---B---C   <-- branch 1
>                \
>                 \-a---b---c   <-- branch 2
>
> Usually working with grafts, examining result in gitk, then commiting
> grafts using git-filter-branch is the solution for such history
> rewriting.
>
> -- 
> Jakub Narebski
> Poland
> ShadeHawk on #git

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html