[Mono-dev] The new world of Git -- what else can we change :-)

[Avery Pennarun]

On Wed, Jul 28, 2010 at 10:52 AM, Miguel de Icaza <miguel at novell.com> wrote:
> * Real release branches, these have value in that we can determine what we
> shipped when.   The older the release, the lesser the value.

Using tags for this works just as well, and lets you move the names
out of the "more obvious" branch namespace.  When you do "git branch
-a" (or just look at the branches dropdown in github) that way it'll
only show the recent branches, which are the ones you're most likely
to want to check out.

You can always convert a tag back into a local or remote branch if it
turns out you shouldn't have deleted it after all.  Unlike svn, in git
creating/deleting a branch is really a non-operation (it doesn't
affect the repository or the history at all).

If there is a chance that a branch is still under active maintenance -
ie. that you might commit more stuff to it to fix a bug in an ancient
release - you should probably keep the branch around.  But again, if
you guess wrong, you can always just re-create a deleted branch and
pick up where you left off.

> * Work branches for code that was eventually merged: I could not find a
> single branch of these that was worth keeping around (C5, SAVANNAH_CVS,
> NUNIT, XIMIAN, anonymous-methods*, atsushi*, dick*, jb*, martin*,
> messaging*, mwf*, post*, sports-model, vargaz*)

Note that because svn (at least older versions, which presumably were
being used in the past) doesn't retain the history of individual
changes across merges, deleting these branches could lose important
information about copyright and who-contributed-what.  So keeping them
around somewhere (either as tags in the current repo, or in a separate
history repo) is probably wise.  Of course, if the svn repository is
going to stick around forever anyway, that's less important.

> I do not understand tagging, but if that is a real solution, we could use
> that for the pre-Mono 2.4 releases, as well as the old Moonlight branch
> releases.

In git, branches and tags are both really simple.  They are exactly
this: a link from a name (branch name or tag name) to a commit id
(sha-1 hash).  The only difference is that for a branch, git will
automatically update the link to point at the new commit when you make
one; for a tag, git only updates it if you update it by hand.

So deleting a branch is just deleting a text file named 'branchname'
that contains the commit id.  Creating a branch is just re-creating
that file (so as you can imagine, it doesn't affect the history at
all).  Changing a branch to a tag is just moving that file from
refs/branches to refs/tags.  Of course there are git commands to do
this, but you can do it just by moving files around in the filesystem
if you want to prove it to yourself :)

Have fun,

Avery