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?
<GITLAB>
<https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html>
"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."
</GITLAB>
Or the "Fast-forward merge?"
<GITLAB>
<https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html>
"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."
</GITLAB>
HOWEVER: These things look like they're with Enterprise Edition paid
versions, not Community Edition.
<https://about.gitlab.com/pricing/#saas>
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.
<https://about.gitlab.com/handbook/marketing/product-marketing/#open-source-projects-on-gitlabcom-get-all-gold-features>
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
