tl;dr - I am also -2 on merge commits, not entirely sure about ff either, they tend to be work, cherry-pick would be preferable.
Long version: Currently we do have a strategy in place, that is called "Cherry-Pick". Basically it means, that Gerrit resolves any branch conflicts (the patch had been developed on an older commit then the current master has) and just cherry-picks the change. It has two basic advantages: 1. It prevents "merge-branch" commit messages and therefore keeps the master history clean, but also 2. it prevents the developer from rebasing on master before merging the change. Different to cherry-pick, merge branch strategy will also try to merge the commit together with the master branch. But in the scenario described above, it can lead to scenarios where the two branches are out of sync, and now git* will create a merge-commit to move them on the same track again. There are two major issues with that strategy: 1. it pollutes history. It will end up creating a bunch of those merge requests, as long as the developers don't take rebase seriously and 2. it increases the risk that a merge will overwrite newer changes, an absolut no-no. It usually is deployed either in small projects or together with a very complete CI/CD integration with nearly 100% automatic functionality testing. In bigger projects it is a very bad idea in my opinion. Now fast-forward is the strictest of it all, although a little bit similar to cherry-picking. It is used to absolutely ensure, that the commit history is clean. It basically means, that your merge request will have to happen on the very top of the commit history of the branch you want to merge into. This means, that the developer has to ensure that the patchset can be merged, no automatic resolving takes place. It is more cumbersome to work with, especially in projects where a lot of people commit. To my recollection the collisions have to be resolved only for the files touching the merge request, making it a little bit less strict, but still it requires additional effort on the side of the developer. (see https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html for gitlab's explanation, at the bottom they have a very good overview of what it entails). Personally I have ever worked with fast-forward and cherry-pick. The first is an absolut must if code traceability has to be ensured (e.g. for machine safety applications), the latter for projects which want a very clean main history (e.g. for release notes) and also avoid extra checks for feature branch merges (due to the nature of overwriting existing changes on chance with merge-only strategies). Therefore I am very strongly opposed on merge commits and would prefer fast-forward. If we go with merge commits we would need other features and workflows to ensure, that no overwrite can take place or it is detected properly if it happens. regards Roland Am Sa., 12. Okt. 2019 um 12:09 Uhr schrieb Graham Bloice < graham.blo...@trihedral.com>: > As one who has never used GitLab, I'm uncertain about the changes. > To educate me can anyone point to an instance of a merge commit in another > project? > > If I understand them correctly (which might not be true) then I'm a -2 for > merge commits. I really do NOT want to see master commit history polluted > with the details of the sausage making, just the effective change. > > To clarify discussion on this I would like to see detailed workflows of > both approaches (ff only and merge commits), i.e. intial change creation, > amendment, approval and merge to master, along with any tooling (e.g. > similar to git-review) that makes the process easier. > > When we have the workflows laid out then we then have a basis for > discussion as to which fits the project needs better. > > > On Sat, 12 Oct 2019 at 02:28, João Valverde < > joao.valve...@tecnico.ulisboa.pt> wrote: > >> >> On 11/10/19 22:54, Gerald Combs wrote: >> >> The reactions to migrating so far have been pretty favorable, so I've >> started documenting the process at >> https://gitlab.com/wireshark/gitlab-migration/wikis/home. There are still a >> lot of things to figure out, but I'm hoping that we can start preparation >> and testing some time in November and cut over the repository in mid January >> (the 14th will be the 6th anniversary of the Subersion-to-Gerrit cutover). >> >> Awesome. Also +1 for merge commits from me. Sadly I haven't really seen >> anyone else advocating for this. >> >> I agree it's nicer to look at a linear history but the workflow is better >> with merges. >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe > > > > -- > Graham Bloice > Software Developer > Trihedral UK Limited > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
