[petsc-dev] v3.5 release schedule

[Barry Smith]

  Is it my fault that git was so badly designed it requires perfect humans to use "properly"? Clearly a lot more thought about its usability should have been gone into the design of branches. They are a really useful concept but something about them has turned them into unusable hairballs. Even freaking saws that nobody works on has 40 branches at bitbucket while petsc has 99+ (what does the + means, it might have 400?)*. But bitbucket shows them in a dinky window that can display 7 at at time with the only information displayed is their name: how about displaying their current status in some reasonable way. This is absurd, git/bitbucket/something needs some far better mechanism to track and mange branches then just having a big freaking list of (mostly) meaningless crap plus some useful stuff that is lost in the mass.

  branches have purposes but there doesn't seem to be a way to properly indicate this. When created each branch should at a minimum know where it came from, have a purpose the user can type in and a plan for where it is intended and if it is intended as a one time fix etc and that should not all be encoded in the branch name.

For example:

root branch             purpose                                     intended destination        planned lifetime                                                                          Current status

maint              fix error in spelling of Jed's name       maint, next, master         until put into maint and master                                                      merged into next
master            add cool new feature                          next, master                    keep around for bug fixes since Barry is a crappy coder              previous cut merged into next, new stuff added not yet merged into next
barry/saws      try a new feature with saws               barry/saws                       until put into barry/saws                                                               new stuff in there not merged into barry/saws.



  Barry

* and don't say, this is just because you haven't cleaned them up recently and go "clean them up". They should be managed properly by the system and not require "cleaning up" by a git guru.


   

   
On Oct 6, 2013, at 9:06 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>>   If someone "fixed" a branch like this why won't they merge it into
>>   master or next? Likely because they "forgot" that step? If this is
>>   the case then I will point out yet again this is a flaw with the
>>   tool, not the person. Any software that assumes and requires the
>>   user do the right thing every time is crap software. If a branch is
>>   already merged into next or master is there some way when a person
>>   does a commit on the branch in the future it asks or reminds them
>>   if they want to merge into next or master, i.e. reminds them right
>>   there and then what they should do?
> 
> How do we decide this programmatically?  That is, how do we distinguish
> between a new branch starting from 'master' and one that has already
> been merged?
> 
> If "git merge-base master HEAD" is not a first-parent ancestor of
> 'master', then something in our history was merged back to 'master'.
> This does not distinguish:
> 
> 1. 'alice/prereq' starts from 'master' and merges into 'next'
> 2. 'bob/enhancement' starts from 'alice/prereq'
> 3. 'alice/prereq' graduates to 'master'
> 4. Is Bob's next commit a "bug-fix" or just unmerged work?
>