Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
On 14.10.2019 21:22, Frederik Schwarzer wrote: > If however, master had seen commits as well, fast-forwarding is > performing a rebase ... is that correct? The workflow would be: whenever master is updated, you rebase your local feature/work branch and force-push to the remote copy of the feature/work branch. That way you would get a linear commit history whenever you merge the feature/work branch to master. People reviewing your work should be prepared to reset --hard to the origin whenever that happens. There are two caveats with this model: - one: you should never accept MRs which are (partially) behind master, because the person who merges things in should not modify what is being merged in. Rather the person who proposes the merge should take the time to do the necessary rebase, because they know best how to do that. - especially when working with many people on the same code-base there should be reasonably fast paced dev -> MR -> review -> merge cycle. Long lived feature/work branches are really bad because as time goes on it becomes fairly difficult to keep them up to date. Regards, -Johan
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
On 14.10.2019 21:22, Frederik Schwarzer wrote: Hi, just asking in case I didn't get it. I branch off of master and do a few commits in that new branch. If I now merge the branch back to master and master had not seen any commits in between, it's just relocating the master "tag" and all is fine. If however, master had seen commits as well, fast-forwarding is performing a rebase ... is that correct? Yes Wouldn't rebasing be evil because it rewrites history? Well, it only rewrites your personal branch. Just don't tell anybody :) In all seriousness though: it's not specific to gitlab, you're supposed to rewrite history to address code review anyway. It would be the same even with mailing-list-managed projects: somebody says "No, it would be better if 3-rd and 4-th patches would be joined into one", and now to do it you need to rewrite your local commits history.
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
Hi, just asking in case I didn't get it. I branch off of master and do a few commits in that new branch. If I now merge the branch back to master and master had not seen any commits in between, it's just relocating the master "tag" and all is fine. If however, master had seen commits as well, fast-forwarding is performing a rebase ... is that correct? Wouldn't rebasing be evil because it rewrites history? Cheers Frederik On 10/14/19 6:29 PM, Johan Ouwerkerk wrote: Yes, please, pretty please with cherry on top. :) Regards, -Johan On Sun, Oct 13, 2019 at 10:57 PM Albert Astals Cid wrote: I find the merge behavior to be not what we've been doing in phabricator so given the idea is to maintain our workflows i'd appreciate if we can agree on continue doing the same. https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html Opinions? Cheers, Albert
Re: Get Hot New Stuff Dead or Alive?
On Sunday, October 13, 2019 1:57:06 PM EDT Ben Cooksley wrote: > On Mon, Oct 14, 2019 at 6:06 AM Allen Winter wrote: > > > > or maybe renamed? > > Hi Allen, > > > > > How do I find out if there are any GHNS for KOrganizer. > > The Import->GHNS menu in KOrganizer starts and I see the import dialog ok. > > but that dialog is empty. > > > > I need to know if something is broken with the KOrganizer implementation > > or if I should remove that feature. Or maybe just nothing to import, which > > makes me think I should remove the feature. > > > > > > As a first starting point, i'd suggest asking what endpoint your > implementation is reaching out to. > Depending on when it was last updated, there are at least 3 different > places KOrganizer could be trying to fetch from. > > Two of them are essentially static, unchangeable archives for legacy > implementations now, while the other one is store.kde.org. For KOrganizer, NewStuff is both dead and alive :) there are some importable calendars .. but they are ancient. anyway, I have a phab patch that Laurent is helping me fix properly. thanks for the help Ben
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
Yes, please, pretty please with cherry on top. :) Regards, -Johan On Sun, Oct 13, 2019 at 10:57 PM Albert Astals Cid wrote: > > I find the merge behavior to be not what we've been doing in phabricator so > given the idea is to maintain our workflows i'd appreciate if we can agree on > continue doing the same. > > https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html > > Opinions? > > Cheers, > Albert > >
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
On Mon, Oct 14, 2019 at 1:42 PM Aleix Pol wrote: > > On Sun, Oct 13, 2019 at 10:57 PM Albert Astals Cid wrote: > > > > I find the merge behavior to be not what we've been doing in phabricator so > > given the idea is to maintain our workflows i'd appreciate if we can agree > > on continue doing the same. > > > > https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html > > +1 > > This is the enterprise version though, does this apply to the community? All of their docs are under the /ee/ path on docs.gitlab.com - for the most part they're fully applicable to CE though. Features that are EE only are marked with the corresponding EE versions (see https://docs.gitlab.com/ee/user/project/insights/ for instance) > > Adding sysadmin as CC, since they're the ones who will have to put it > to work in the end. We received a request for this a little while ago - please see https://phabricator.kde.org/T11190 While we did investigate this, as it turns out this is part of Gitlab that is non-customisable in terms of the default (regardless of your edition). What we will likely end up doing is changing all projects to that setting via the Gitlab API following the rollout of Gitlab to all projects and ensure we change that configuration for new projects as part of the project provisioning process. Please note that our current Gitlab setup should be considered to be an evaluation system, hence why we haven't looked into implementing this yet. In terms of this request though: 1) Work branches will eliminate most of the problems and pain you're experiencing here I suspect 2) Forcing rebases to land changes means that you will be unable to land changes that comprise more than 100 commits, as may be the case with larger bodies of work. In terms of why (2) happens, this is because our commit hooks, in order to prevent abuse/flooding of common spaces (such as #commits on Freenode, and the kde-comm...@kde.org mailing list) block attempts to push greater than 100 commits. From the perspective of the commit hooks, rebased commits are entirely new commits - and any commit coming from a work branch (once those are introduced) will also count as a new commit. Our hooks do operate on merges performed by Gitlab and will result in Gitlab returning 'Something went wrong' when you try to merge in changes greater than 100 commits as the hooks will block Gitlab from performing the (rebased) merge for you. In these cases, should we proceed down the path of not creating merge commits (and requiring rebases in the event of it being a non-fast forward) then projects will need to perform the merge manually in these instances, or ask Sysadmin to temporarily switch them back to the Gitlab default of creating merge commits in order to land that series of changes. > > Aleix Cheers, Ben
Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?
On zondag 13 oktober 2019 22:57:20 CEST Albert Astals Cid wrote: > I find the merge behavior to be not what we've been doing in phabricator so > given the idea is to maintain our workflows i'd appreciate if we can agree on > continue doing the same. > > https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html > > Opinions? > We made that the default for Krita as well. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.
