Re: improving our workflow with better tools - let's test things.

[Trevor Daniels]

Joseph Rushton Wakeling wrote Monday, October 21, 2013 6:50 AM

> On 21/10/13 06:13, Carl Sorensen wrote:

>> What me drives crazy is the structure of the main git repository.  If
>> you follow github style, the graph gets littered with zillions of
>> `merge request' commits, one per pull request, which makes it quite
>> hard to follow the development IMHO.

> It's true it can get annoying if you have lots of one-commit contributions.  
> On 
> the other hand it lends itself to being able to split your contributions into 
> multiple separate commits for which the main git history simply gets a 
> summary 
> (the merge commit).
> 
> I still think it's ultimately worth it for the discipline of "No one pushes 
> directly to master", which helps enforce a requirement that everything gets 
> tested and reviewed, even stuff by core developers.

The vast majority of my contributions are single-commit, and I
suspect most other contributions are the same.  They are easy
to manage and generate a clean history with merge commits 
appearing only when they are appropriate.  Our git repository was
not always managed in this way, so the advantages of a clean history 
are obvious, at least to me.

Our current workflow already enforces: "No one pushes directly to master".  
Why is it "ultimately worth it" to lose a real advantage only to regain 
something we already have?

Having worked with Carl for some years I respect his opinion,
and for me his bottom line: "I'm seriously thinking of junking
Gitlab because the benefit seems to be more promised than realized",
based on his experience of actually using Gitlab on a real project 
clinches the matter.

Trevor