Squash merge vs normal merge

[kobebryant432]

@Ivanderkelen I noticed that our dev branch is very commit heavy (there are +200 commits). This is because we merge pull requests using the standard merge technique being - add all commits from this branch to the dev branch. Another strategy is to squash merge which combinds all commits into one commit. This is cleaner.

As admins we can limit the options users have to merge. Initially i thought to limit this to squash merging but for very large changes having the full commit history is usefull (e.g. the CLIMATE_GRID_INPUT convertor). Squash merges bundel commits into one coherent adaptations and avoid commits like "bug fix" or "typo" on the main branch commit history making it easier to undo grouped commits but some information and undoing individual commits is no longer possible.

What are your thoughts? For an example see the last two commits (squash merges) in dev.

Currently I recommend leaving both options open and using squash merge for most pull requests except really big additions/changes.

[Ivanderkelen]

This is really usefull - and I fully agree with your take.

Also the amount of commits is user dependent -- I am a person making many very small - sometimes useless commits. (eg in the development of CLIMATE_GRID convertor, I switched often between hortense and kili and therefore had to do a lot of merges with conflicts etc etc). I fully agree to merge commits therefore into one.