Gitlab experiment wrapup

[Huw Davies]

On Thu, Jun 16, 2022 at 09:08:30PM +0300, Gabriel Ivăncescu wrote:
> On 16/06/2022 20:13, Alexandre Julliard wrote:
> > Alex Henrie <alexhenrie24 at gmail.com> writes:
> > 
> > > On Thu, Jun 16, 2022 at 10:04 AM Gabriel Ivăncescu
> > > <gabrielopcode at gmail.com> wrote:
> > > > 
> > > > There's one other (pretty big, for me) problem I can't seem to find how
> > > > to replicate with MRs compared to sending patches: how do I add notes
> > > > for each commit that shouldn't actually be committed? For patches I used
> > > > to add below the --- line, and these are super useful when you just want
> > > > to tell the information to the reviewer, which wouldn't make much sense
> > > > to have in the codebase itself.
> > > > 
> > > > These seem to get lost when I push. I have to admit `git notes` seems
> > > > pretty convoluted to me and I've no idea how it gets "stored" especially
> > > > for merge requests. Patches were much easier to comprehend.
> > > > 
> > > > I mean, I guess I can add it to the MR description but that's not
> > > > pointing out to a specific commit/patch... sigh.
> > > 
> > > In a GitLab merge request, I can click on a specific commit to see its
> > > diff, then click on the commit hash again, and GitLab gives me a box
> > > to leave a comment either about a specific line of the commit or about
> > > the commit as a whole. Would that work for you?
> > 
> > Unfortunately comments tied to a specific commit are no longer visible
> > when the branch is rebased, for instance when a reviewer pushes fixups.
> > There's a issue filed with Gitlab about that, but until this is fixed
> > it's better to avoid commit-specific comments.
> > 
> 
> I might go with a normal comment (after a MR is created or after a force
> push for e.g. v2), with something like:
> 
> 
> 
> **Notes for `ntdll: Foobar`**
> 
> Notes go here.
> Multiple lines.
> etc.
> 
> **Notes for `server: Barfoo`**
> 
> v2: blah.
> 
> 
> 
> and so on. Which can also be scripted (and easily taken from own git notes).
> For example with something like:
> 
> git log --reverse --pretty='format:**Notes for `%s`**%n%n%N%n%n'
> origin..HEAD
> 
> Maybe we can standardize on a common method to encourage and put in the
> wiki? Well, or maybe it's just me.

Feel free to do that, but it sounds over-engineered to me and I don't
think we need to standardise this.

Personally, I've always found these sort of comments somewhat fragile.
When I'm reviewing a series I'm reviewing it in-tree, at which point
the comments have gone.  Putting them in one place (in the equivalent
of a cover-letter) means there's more of a chance that I'll read them.

Huw.