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

[Jon Frisby]

This isn't QUITE accurate.  Tags are intentionally harder to change precisely because they are intended to have a degree of 'permanence' and be outside of the day-to-day workflow that branches are for.

To that end, they include another important feature that branches do not, which is the ability to sign the tag when it's created, which gives you some assurance that the tag is from who it claims to be from (making trustworthy releases possible in a DVCS environment).

So yes -- generally speaking all releases 'should' be tagged if you want to keep things git-ish.

As for the question of branches, I've become fond of the idea of using an ad-hoc hierarchy of names starting with the name of the branch's 'owner' and with other namespaces for branches that are considered shared/important.  So I might have jfrisby/MonoTouch/MyTopicBranch, and whether or not I push it up to github.com/mono/mono.git is a function of how much value I perceive there to be in sharing it in that manner -- although I would almost certainly push it to github.com/jfrisby/mono.git regardless.

-JF

On Jul 28, 2010, at 3:58 PM, Avery Pennarun wrote:

> 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
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list