Re: [boost] [git] neglected aspects

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

Thomas Heller wrote:

> On 02/11/2012 03:48 PM, Julian Gonggrijp wrote:
> 
>> 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.
> 
> You gotta be kidding me, right? Even with the most awesome tool in the world, it is trivial to see that this adds overhead! While by simply committing stuff, i just have to issue one command and be able to observer that everything still is alright.
> You already listed forking and merging as two different steps!
> Come on ...

Alright, sorry. I admit I was a bit too enthousiast there.

>> 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.
> 
> Yeah, this all sounds very nifty ... in theory. This all means overhead in terms of commands to issue and quality assurance that everything went right, including running tests after the merge (did it really merge everything correctly), resolving possible conflicts etc.

Yes, resolving conflicts after a merge is probably the main term of 
added overhead when branching. I think that gitflow allows for a 
working style that reduces merge conflicts, though, and ironically 
that's mostly because of the use of additional branches.

> While I admit that all this branching sounds very tempting, please don't try to sell me as a fool that all this comes without a cost. This is just not true.

Agreed, the proposed branching model does have a cost.

>>> 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 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.
> 
> Yes, I mean the hardware description language. Let me explain:
> In VHDL you usually start prototyping your new design by writing some behavioral description at a very high level, almost like you do with a "normal" programming language. After you are done, you start to write your unit tests for that. You do that by writing a very generic unit test and refer to your new design as "device under test". After you successfully passed all the tests, you start by getting down one level in the abstraction, lets say RTL level (Register transfer level). After that you plug that new device into your unit tests to ensure correct behavior.
> Now, imagine that different branches are seen as different devices, so to say. Instead of letting the test runners run the unit tests defined in the main branch, you let'em run the unit tests in your new feature branch, completely transparent for them. This means that you don't need to disrupt regular service by committing a half done feature to the main branch, but get the full advantage of the different test runners.

I need more time to absorb this, but it does sound very cool indeed.

-Julian