On Thursday 20 Feb 2014 21:40:25 Ben Cooksley wrote: > >> I tried working with github for a project, using a workflow of reviewing > >> each commit. I personally really disliked it for creating a merge commit > >> for each commit, that just clutters up the history (try looking at any > >> github project with a few contributors). > >> > >> Is this the same with gitlabs or can it cherry-pick after successful > >> reviews? > > > > In both, github and gitlab you can have teams that have access to a > > repository, those team members do not need any review. > > > > If we want to continue with our policy of "KDE hackers can commit > > everywhere" then we just have to create a team with all of us on it. > > At this point in time, that policy will be continued. > Merge Requests could be used by other developers if they wished however. > > In terms of whether it's automatic merge creates a history mess, this > is unknown - it will likely come out in testing I imagine. > It also offers information and instructions on performing the merge > manually.
I use Github for several small projects, and I also dislike lots of small merges. I simply perform manual merges or cherry-picks, and when I push back to Github, it almost always notices and does the right thing: marking pull requests as merged, listing the relevant commits on related issues, etc... Hopefully, Gitlabs can/will do something similar. Paul
_______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
