Qmx - could you write in this thread how these changes would effect the workflow? Also what would happen when users have overlapping topic branches going at the same time? The image you provided looks very linier. I just want to make sure I understand it better, so we can discuss it.

Note that I've also created the AeroGear Licensing and Copyright page and have updated the AeroGear IDE config repo with the correct license and copyright information. Note that these updates are in the aerogear branch, which is now the default branch for that repo.

Qmx - could you write in this thread how these changes would effect the workflow? Also what would happen when users have overlapping topic branches going at the same time? The image you provided looks very linier. I just want to make sure I understand it better, so we can discuss it.

My suggestion boils down on relaxing the "squash to one commit rule", meaning that it's good to keep history (given that the history is meaningful (usually it is).

About it looking very linier, that's exactly how it should look. Before doing the no-ff merge, you rebase your branch to keep the history linear, and in this case, linear != having no merge commits. I started adopting this practice after suffering to find a regression on a 20-commit-squashed-to-one

My suggestion boils down on relaxing the "squash to one commit rule", meaning that it's good to keep history (given that the history is meaningful (usually it is).

I agree with relaxing the "squash to one commit rule" - I think there is some wording around that. I'll update make it clear that your only need to squash trivial commits.

Douglas Campos wrote:

About it looking very linier, that's exactly how it should look. Before doing the no-ff merge, you rebase your branch to keep the history linear, and in this case, linear != having no merge commits. I started adopting this practice after suffering to find a regression on a 20-commit-squashed-to-one