From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Fri, 10 May 2019 09:48:34 -0400 Message-ID: References: <1552789070.5272.1@yandex.ru> <87imwhmmt8.fsf@gmail.com> <87y347g1l3.fsf@iotcl.com> <9ac21e82-8e47-f9b5-f88d-23c0c56946d1@yandex.ru> <87pnpc1lby.fsf@iotcl.com> <83zhoezdqc.fsf@gnu.org> <87imuivfcr.fsf@iotcl.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="219358"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , dgutov@yandex.ru, agrambot@gmail.com, emacs-devel@gnu.org To: Toon Claes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 15:50:11 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hP5ud-000uu8-E4 for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 15:50:11 +0200 Original-Received: from localhost ([127.0.0.1]:43713 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP5uc-0006mn-8N for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 09:50:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP5tE-0006Pw-3e for emacs-devel@gnu.org; Fri, 10 May 2019 09:48:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hP5tC-00033Y-Ve for emacs-devel@gnu.org; Fri, 10 May 2019 09:48:44 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:54541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP5tC-00032R-QZ; Fri, 10 May 2019 09:48:42 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x4ADmZ1F019334; Fri, 10 May 2019 09:48:35 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E1D156AE94; Fri, 10 May 2019 09:48:34 -0400 (EDT) In-Reply-To: <87imuivfcr.fsf@iotcl.com> (Toon Claes's message of "Fri, 10 May 2019 11:16:52 +0200") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Rules: 3 Rules triggered TRK_NCM1=0.1, EDT_SA_DN_PASS=0, RV6543=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6543> : inlines <7074> : streams <1821123> : uri <2842750> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236370 Archived-At: > This probably still a shortcoming in GitLab. You are right, to get the > code locally, you need to fetch and checkout the feature branch the > contributor created. Ideally for me, the merge-requests should appear as branches within the *emacs.git* repository (e.g. in refs/merge-requests/?) so I can just always fetch all the merge requests when I `git fetch` and have them available locally? [ Note: ideally for me, the above should also hold for the message part of the merge requests, and by extension for the issue requests as well. ] > Yes, I tried to stress the importance of email too. I regret to hear the > email interface of GitLab didn't work for you. I'll have a look whether > I can suggest changes to make the "litter" configurable. But besides > from that, are there any other annoyances you've encountered so far? The "commit-diffs" I get on my Gitlab projects are acceptable but less readable than those we get for emacs.git (ideally, they should have the patch part in 100% standard patch format as an attachment, so a local email client like Gnus can render them in the way the user likes: it's OK to also include an HTML version with a Gitlab-chosen rendering of the patch, tho, so I guess I'm mostly talking about the "text/plain" side of the multipart/alternative). > I hate to admit it, if email is the top priority, then maybe > https://sourcehut.org/ is a better alternative than GitLab. It sounds promising, indeed. But when I tried to install it to play with it on my end, I found that it relies *too much* on email for me to be able to install it easily (I don't have easy admin access to an SMTP server). Stefan