Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-02-11 09:48:47

Thomas Heller wrote:

> On 02/11/2012 01:42 PM, Julian Gonggrijp wrote:
> 
>> So the perceived problem is that it would take too much time for the
>> volunteers to check out all of the numerous feature branches that
>> might exist at any given moment and test all of them, in addition to
>> the develop branch and the current release branch. The practical
>> consequence is that features under active development cannot be tested
>> on all platforms until they're merged back into the develop branch.
>> 
>> Here's why I think this isn't a real issue.
>> 
>> [...]
> 
> Right, that all makes sense. However, the whole branching stuff seems like a lot of overhead (even if the tool is able to handle it very good).

Please take my word that the branching stuff doesn't add any overhead. 
Forks and merges are just special cases of commits:

Commit - create a new commit with one previous commit as parent.
Fork   - create a new commit which will have a sibling from the same 
         parent.
Merge  - create a new commit with two parents.

That's all there is to branching in git. History is a directed acyclic 
graph of commits with parent relationships. Under the hood, a branch 
is nothing more than a bookmark to a leaf commit.

> Mind you, we, the developers don't always have all the toolchains available on our developing platforms.
> What would make this whole branching very cool is if we could somehow tie it with testing such that we are able to tell the testrunners to use our feature branch to run the tests (of course this must be automated in a way).

I agree something like that could be nice, but I think the gitflow 
model is already very cool without it. :-)

> I think in this scenario, a modularized boost will come in very handy ... Think of the VHDL model,

Do you mean this? http://en.wikipedia.org/wiki/VHDL

> you have unit tests, but the module under test might be very different, though the unit tests stay the same. This is something i would really like to see.

Could you clarify? I don't see why we would want to test a different 
module with the same unit tests.

-Julian