Thread (5 messages) flat view 5 messages, 2 authors, 2016-06-15

Re: How does git store branchpoints?

From: David Copeland <hidden>
Date: 2016-06-15 22:44:43

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:
davetron5000 [off-list ref] writes:
quoted
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help