On 4/9/2018 2:15 PM, Carl Sorensen wrote:
If we use merges instead of single commits, we know that the final result (the 
merge commit) is OK, but we don't know anything about the underlying commits in 
the branch being merged.  Some of those commits may not build properly.  I 
guess those commits won't be on master, but all of the interesting history is 
in those commits, not in the merge commits.

No experience here, just researching.

How about the GitLab Enterprise Edition's "Squash and Merge" feature?



"Squashing lets you tidy up the commit history of a branch when accepting a merge request. It applies all of the changes in the merge request as a single commit, and then merges that commit using the merge method set for the project."


Or the "Fast-forward merge?"



"Sometimes, a workflow policy might mandate a clean commit history without merge commits. In such cases, the fast-forward merge is the perfect candidate... If the target branch is ahead of the source branch, you need to rebase the source branch locally before you will be able to do a fast-forward merge."


HOWEVER: These things look like they're with Enterprise Edition paid versions, not Community Edition.


I gather they'd give their top-of-line "Gold" level hosted service for free to Open-Source projects, so those features could be available for LilyPond without lots of extra cost.


Whether terms of service and such are aligned with GNU standards is something I haven't checked.
Karlin High
Missouri, USA

lilypond-devel mailing list

Reply via email to