GitHub

[David Golden]

On Tue, Jun 2, 2009 at 12:34 PM, Andy Armstrong <andy at hexten.net> wrote:
>> (2) branches -- you seem to have branches for each project that point
>> to the same commit. Those should be eliminated.
>
> OK - huge gap in my understanding of git here. Surely a git branch contains
> everything in the project, no? I didn't think there was a way to have git
> know that the different subdirectories are different projects. What should
> the branches look like?

We might be talking past each other. I see these:

$ git branch -av
* master                        059547b Git conversion: all appears to
work. Just need the all-clear from SPURKIS now :)
  origin/HEAD                   059547b Git conversion: all appears to
work. Just need the all-clear from SPURKIS now :)
  origin/TAP-Formatter-TextMate 059547b Git conversion: all appears to
work. Just need the all-clear from SPURKIS now :)
  origin/TAP-Harness-Archive    059547b Git conversion: all appears to
work. Just need the all-clear from SPURKIS now :)
  origin/Test-Harness           059547b Git conversion: all appears to
work. Just need the all-clear from SPURKIS now :)
  origin/Test-More-Diagnostic   059547b Git conversion: all appears to
work. Just need the all-clear from SPURKIS now :)
  origin/tap-tests              059547b Git conversion: all appears to
work. Just need the all-clear from SPURKIS now :)
  origin/trunk                  059547b Git conversion: all appears to
work. Just need the all-clear from SPURKIS now :)
  ...

All of these branches point to the same commit, so they are identical
and you can delete all the TAP/Test/tap branches.  Probably "trunk"
too as it's confusing compared to 'master' which is the git default.

On branches, not that I'm a git expert, but here's my understanding:
a branch is just a reference to a particular commit and a commit
references a directory tree.  A directory tree contains SHA1's
referencing the blobs representing each file.  Commits also contain a
link to (one or more) parent commits.  All a branch really does is
indicate which commit should be the parent for a new commit "on that
branch".

It's a DAG, but the 'arrows' point from the leaf nodes back towards
the root, so rather than keep a pointer to the root to walk the tree,
you have pointers at every leaf node.  Those are the branch pointers.
 You use them to navigate back through history or else tack on a new
node and update the branch pointer.  And, of course, you can create a
branch that points to a commit in history, which will become the
parent of a new commit splitting off from history at that point.

Branches are just paths to files under .git/refs/heads containing a
commit id, so you can make them hierarchical.  E.g.:

    $ git branch test-harness/replace-open3-with-capture-tiny
    $ git branch -v
    * master                                       059547b Git
conversion: all appears to work...
      test-harness/replace-open3-with-capture-tiny 059547b Git
conversion: all appears to work....

The branch is here:

    .git/refs/heads/test-harness/replace-open3-with-capture-tiny

And it contains the same commit id as the 'master' branch as I haven't
committed anything to it, yet.

So sub-project branches can be organized by their path names and you
don't have to create anything in advance.  You might consider doing
something like this for each project, however,

    $ git branch test-harness/_create_branches_here_
    $ git branch tap-harness-archive/_create_branches_here_

That sets up the directories in the master repository and would help
signal to people how you would like them to create branches.

(I've never worked on a multi-project git repository, so I'm
brainstorming this as I go.  Fee free to take my suggestions with some
grains of salt, a shot of tequila and a lime chaser.)

>> Likewise, you have
>> some branches that appear to have been deleted in the past and have
>> been resurrected.  See "git branch -av" for list of branches plus last
>> commit id/message.
>
> That'll be something to do with the script that munges the svn repo. I'll
> see if I can find out where they're coming from.

I'm sure they're getting created when svn2git replays the svn commit
history into git and just not deleted since there's probably no easy
way to distinguish a "branch delete" in subversion.

> Yeah, they just all got sucked in. I assumed we'd just delete them from git.

You can kill them after the svn2git by just deleting
.git/refs/heads/<whatever> before you push to github.  (Or use "git
branch -D <whatever>" from inside the right repository).

-- David