[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFE] Migration to gitlab

From: Stefan Monnier
Subject: Re: [RFE] Migration to gitlab
Date: Fri, 10 May 2019 09:48:34 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> 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/<foo>?)  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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]