Re: Migrate to GitLab?

[Roland Knall <rknall () gmail com>]

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.bloice () 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.valverde () 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-request () 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-request () 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-request () wireshark org?subject=unsubscribe