Re: Gitlab Migration

[Dmitry Gutov]

On 29.08.2021 09:55, Drew DeVault wrote:

> > - Every version of a patchset is re-submitted as a whole. I suppose
> > there is some purity in that, but if for example the original submission
> > is big, and I only asked the author to change a few relatively minor
> > things, I prefer they do that in a separate commit. Then, in a git**b
> > workflow, I see that the branch was updated with that one commit, and I
> > don't have to scan the other commit(s) for any unrelated/breaking
> > changes.
>
> This is a bad practice for git, because it makes the history worse. This
> has consequences, for example, with tools like git bisect.

Depends on how the changes are organized, whether there will be breaking 
builds, and whether commits include back-and-forth changes in the same 
place.

In the end, a branch-driven workflow can ask for a single rebase before 
the changes are merged to master (with fixups, squashes, etc). Which 
should fix the later problems with bisecting and give cleaner history, 
without having all the patches resent for every round of review.

> Instead, git
> range-diff is helpful for comparing the previous and new version of a
> patch, and future improvements to the web UI will incorporate it to
> allow you to easily diff between patchset revisions. The idea is
> something similar to Gerrit's approach, you may be familiar with that.

Haven't used Gerrit (or Phabricator, which I understand includes a 
similar feature). Good to know there is a plan for it, though.

> > - Rebasing. Some of our valued contributors are not 100% comfortable
> > with the more advanced features of Git, rebasing included. Our general
> > recommendation until now has been to prefer merge commits. If the
> > general workflow is going to require people to 'git rebase -i' on a
> > regular basis, it could be a problem.
>
> We wrote another tutorial about git rebase which has been very helpful:
>
> https://git-rebase.io
>
> In general we are a hard "no" on shying away from powerful tools because
> they are intimidating to new users. We prefer to cultivate a culture of
> mentorship instead.

All right. I can live with that. Just want to make sure everybody's on 
the same page about the tradeoffs.

> > - Can we have discussion subthreads "attached" to particular pieces of
> > the submitted patches? Like, a line, or a hunk. Being able to view those
> > in a compact fashion, right in the middle of the context, is pretty
> > handy.
>
> Yes, though it's based on heuristics and we're still working on it.
> Here's a simple example:
>
> https://lists.sr.ht/~mpu/qbe/patches/24383

Thanks. I'm curious to see how it turns out.

> > - Can I jump in in the middle of a patch discussion with a question or
> > an advice and have all subsequent messages in that discussion sent to me
> > too, if I'm not subscribed to the target mailing list? Does that depend
> > on all participants putting me in Cc?
>
> It depends on all of the participants Cc'ing you. It is common practice
> to "reply all" on mailing lists for this reason.

Sure, I'm familiar with it. Hence the questions.

> > - Can I do that "jumping in" from the web interface?
>
> No, but this is a prioritized issue.
>
> > - Can I "unsubscribe" from replies to a topic/thread/patchset I'm not
> > longer interested in?
>
> In a sense. Because you don't have to subscribe to the mailing list to
> participate in a thread, you won't get emails unless the sender has Cc'd
> you. But you cannot stop them from Cc'ing you, and neither can we,
> unless you ask nicely - which is not a software solution. Such emails
> are not relayed by our mail servers, so it's out of our control.

Consider adopting a "common practice" from the Web UI world: every 
discussion (issue/PR/etc) has a unique email address. Every participant 
receives messages "From:" a common address (like notifications@sr.ht) 
but the Reply-To header includes the unique address which will let the 
mail processor on the server associate the reply with the corresponding 
thread and resend it to all participants.

Then anybody will be able to subscribe or unsubscribe from a thread 
without others' cooperation (with different levels, even, where e.g. 
they still get a notification when "mentioned" personally).

As a bonus, it solves the problem of some mail servers/hostings not 
talking to some other mail servers: if you can send an email to sr.ht, 
all others will see it. If you can receive emails from sr.ht, you will 
get all messages.

But it might feel a tad impersonal, I guess. And user error (including 
misbehaving MUAs) can break this approach too.