[Bioperl-l] git branches, tags, 'topic/bug_####'

[Chris Fields]

On May 13, 2010, at 9:38 AM, Jay Hannah wrote:

> So, like this?
> 
> Flow diagram:
>   http://biodoc.ist.unomaha.edu/~jhannah/tmp/branches.png
> 
> master         
>   (git and github default) Trivial changes committed directly here. 
> topic/bug_####
>   One branch per non-trivial Bugzilla ticket 
> topic/jhannah_crazy_idea
>   Branches for unstable/unfinished work
> stable
>   Release manager pulls from master to stable periodically (all tests are passing, etc.)
> release-#-#-#
>   Pulled from stable, pushed to CPAN
> attic/*
>   Any branch with no activity for 1 year
> 
> I like it.

Yes, something along those lines.

>> Re: deletion of branches, I'm only really in support of deleting feature branches that have been merged back to 'master' or another branch (e.g. only removed using 'git branch -d foo').  Older subversion release branches don't tend to fall into that category, in that we had merged or cherry-picked changes from svn trunk to them, not vice versa; they were never merged back to trunk.  Deletion in this case would be somewhat history-revising, correct?
> 
> I'm fine with attic/ and just leaving stuff in there until 2050. Then we should probably delete them.  :)
> 
> My understanding is that by default commits that have no pointers to them (branches or tags or subsequent commits) are subject to cleanup/prune. I think this means that if someone, 10 years ago, committed 3 times to the branch "jhannah_crazy_idea" and that branch is deleted, then those 3 commits may be removed (gone forever) by git cleanup/prune.
> 
> This is a feature or a crime against humanity depending on who you ask. It can be disabled in a normal repo, I don't know about github. 

I don't think this is disabled in github (e.g. one can still delete branches).  Duke Leto suggested the only real way to prevent history revising commits would be to do a pre-commit hook, which is not supported right now in github.

>> Saying that, we could adopt a workflow policy that allows deletion of any merged branch.  All this suggests coming up with a good 'Contributing' document.  Our 'Using Git' is a start towards this, but it's more a general use page and could point to other (possibly better) resources.  I would like something a bit more focused to demonstrate example work-flows and standard practices for those new to git and to BioPerl.  It should also mention how we handle pull requests and other github-related bits.
> 
> As I collect clues I'll be brain dumping everything I think I know onto the wiki. This is a crazy busy week for me though.  :(
> 
> Jay Hannah
> http://biodoc.ist.unomaha.edu/wiki/User:Jhannah

No problem.

chris