[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

--

Graham Bloice

Software Developer

Trihedral UK Limited