Re: Migrate to GitLab?

[João Valverde <joao.valverde () tecnico ulisboa pt>]

On 12/10/19 11:48, Roland Knall wrote:
> 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.

How can a merge commit overwrite changes? I don't understand what you 
are saying.

If you merge a feature branch with n commits and there are conflicts you 
get a merge conflict and need to resolve 1 conflict.

If you rebase a feature branch with n commits and there are conflicts 
you get a rebase conflict and need to resolve up to n conflicts.

Pretty much the same, except the second is potentially more tedious work.

> 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 <mailto: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
>     <mailto: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 
> > athttps://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 <mailto: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
>         <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 <mailto: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
>     <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

___________________________________________________________________________
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