This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to keep Reviewed-by lines in git commits with gerrit.


Florian Weimer wrote:

>>> We should not edit the commit message manually after it has been
>>> reviewed.
>>
>> I agree. Should we setup gerrit to push to glibc git?
>
> I think it's to early for that.

Makes sense.  Keep in mind that as Carlos has mentioned, Gerrit can
be used to manage ACLs for a Git repository without requiring review
(which means that people with a workflow based on pushing after an
on-mailing-list review wouldn't be broken by this).

[...]
>> I would prefer it to be automatically added by the review tool, as
>> gerrit is designed to do.
>
> Is it?

The Cherry Pick and Rebase Always submit strategies[1] automatically
add Reviewed-by footers.

Other submit strategies (like Merge If Necessary) are designed to not
touch the change uploader's commit (e.g. they may have signed it) so
they don't add the footer.

[...]
Carlos O'Donell wrote:

> The determination of a patchset being the "same" involves making
> sure the commit message is unchanged (SHA1 hash doesn't change).

Also keep in mind that reviews can be made "sticky" on commit message
changes.  See [2] for more details.

There's a Gerrit hackathon[3] ongoing as we speak.  If you have any
questions you'd like me to relay to Gerrit devs or if you'd like to
meet up on IRC or video chat, let me know.

Thanks,
Jonathan

[1] https://gerrit-review.googlesource.com/Documentation/concept-changes.html#submit-strategies
[2] https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_copyAllScoresIfNoCodeChange
[3] https://gerrit.googlesource.com/summit/2019/+/master/schedule-usa.md


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]