How does git store branchpoints?

How does git store branchpoints?

[davetron5000]

Following up this:

http://groups.google.com/group/git-version-control/browse_thread/thread/aa34d04120d0c361#

I'm trying to learn/examine the .git directory to see what Git thinks.

What I'm trying to determine is how Git knows the parent of a
particular commit, how I can change it, and how that affects merging.

My problem is that I have two branches, and a merge between the two
produces conflicts in files that are unchanged on one branch.  Since
my branches are linked to SVN branches, I'm thinking that Git is not
properly clear on their shared history.

Any ideas where to look?

.git/info/refs has some strange data in it:

5a3e01a8327c6139e9311b01548baf4a8876b5e3    refs/heads/local-FOO
71560b15ad6a2a7542556dfdf2d6c763625d5db4    refs/heads/local-trunk
efb2ff2ac363600a2aaae60718bc76b6c3db4228    refs/remotes/FOO

The SHA-1 for refs/heads/local-FOO (branch created via git checkout -b
local-FOO FOO) doesn't show in gitk --all, but a git log of that shows
it to be a somewhat old commit (not the head, nor the branch point).

The SHA-1 for local-trunk is a similarly old commit

The SHA-1 for refs/remotes/FOO is the commit right before the SHA-1
for refs/heads/local-FOO in my git log.

Re: How does git store branchpoints?

[Jakub Narebski]

davetron5000 <davetron5000@gmail.com> writes:

> Following up this:
> 
> http://groups.google.com/group/git-version-control/browse_thread/thread/aa34d04120d0c361#
> 
> I'm trying to learn/examine the .git directory to see what Git thinks.
> 
> What I'm trying to determine is how Git knows the parent of a
> particular commit, how I can change it, and how that affects merging.

The parent (or parents in the case of merge commit) are stored in the
commit object itself.  You cannot change them short of rewriting
history, or telling git locally via .git/info/grafts file how it should
modify history (see "Repository Layout" documentation for more info
about grafts).
 
> My problem is that I have two branches, and a merge between the two
> produces conflicts in files that are unchanged on one branch.  Since
> my branches are linked to SVN branches, I'm thinking that Git is not
> properly clear on their shared history.
> 
> Any ideas where to look?

Use some kind of history viewer, be it gitk, qgit, giggle, tig,
git-show-branch (a bit cryptic), git log --graph (not yet released),
or similar tool.

> .git/info/refs has some strange data in it:
> 
> 5a3e01a8327c6139e9311b01548baf4a8876b5e3    refs/heads/local-FOO
> 71560b15ad6a2a7542556dfdf2d6c763625d5db4    refs/heads/local-trunk
> efb2ff2ac363600a2aaae60718bc76b6c3db4228    refs/remotes/FOO
> 
> The SHA-1 for refs/heads/local-FOO (branch created via git checkout -b
> local-FOO FOO) doesn't show in gitk --all, but a git log of that shows
> it to be a somewhat old commit (not the head, nor the branch point).

.git/info/refs is auxiliary information for "dumb" protocols, i.e.
for fetching via HTTP etc.  It is updated using git-update-server-info,
usually in the bare public repositories run from post-update hook
(in non-bare you would want to add it also to post-commit).

What you should look at is "git show-refs" or "git ls-remote ."
output, or "git for-each-ref" output.

> The SHA-1 for local-trunk is a similarly old commit
> 
> The SHA-1 for refs/remotes/FOO is the commit right before the SHA-1
> for refs/heads/local-FOO in my git log.

That said, if you have two divergent branches 'FOO' and 'trunk',
for example with the following history

   a<---b<---c<---d<---e  <--- trunk
             ^
              \---1<---2  <--- FOO

you can derive from parent info where history diverged.

You can ask git to find branch point using "git merge-base trunk FOO",
which should return 'c' (actually, sha-1 of this commit).

HTH.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: How does git store branchpoints?

[davetron5000]

>
> 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.

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.

Dave

Re: How does git store branchpoints?

[Jakub Narebski]

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

Re: How does git store branchpoints?

[David Copeland]

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 <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