Addendum - my initial tl;dr is misleading - I don't like FF because it is extra work, but I definitely prefer it if cherry-picking (as it is applied now) is not an option with gitlab (never looked that up properly). merge is a -2 in any case
Am Sa., 12. Okt. 2019 um 12:48 Uhr schrieb Roland Knall <rkn...@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.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
