Merging strategy

How do people feel about the merge strategy with OpenMRS commits? I just did a rebase on the 1.12x branch and pushed, which resulted in a slightly different history from openmrs. Does anyone feel that its important to keep the same history as the openmrs branch? This would mean that we will have merge commits.

I feel avoiding merge commits is nice. And so would prefer that we use rebase wherever possible when taking code from openmrs, just like we would with a PR. We could also do cherry-picking instead of taking all of commits. But I think we should avoid that until we are in a space where we have many devs. What do others think?

I have always favored rebasing over merging. Cherry-picking would provide a nice linear history.

Between now and my previous post, I realized that contributors who want to send merge request/pull requests to both librehealth and openmrs will have problems if we have different histories. Merge commits make the history look ugly, and rebase might generate different SHAs that will make the code look divergent.

I deleted all the old branches and tags. I did cherry-picking and now all things look fine. I suggest that as a protocol we only do cherry-picking of openmrs commits and do merging for things that come through gitlab merge requests. Seems like an optimal middle path. Do others agree?

1 Like