Re: Allura/SourceForge to Gitlab migration

[Karlin High]

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