On 21/10/13 10:01, Trevor Daniels wrote:
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.
I wouldn't want to do anything to disrupt having a clean git history.
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?
It's not just about "no one pushes ..." but also about having, in the version history, a visible log of both who authored code and who approved its inclusion. I don't think the result is fundamentally less "clean" than the alternative of single-commits-plus-merges-when-necessary; what you actually ought to see is a linear history of one-merge-commit-per-new-feature.
But I accept it's a matter of taste.
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.
Before we risk people getting demotivated, I think we should be clear that at this stage it's unlikely that the advantages of any alternative will be obvious. If they were obvious, all of you would be leaping and jumping to get things set up this way and Janek, Colin and I wouldn't be having to do this exploratory work!
The onus is clearly on us to make the case to you -- I'd simply like to ask that you all keep an open mind while we explore the possibilities.
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
