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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
