This is the mail archive of the
mailing list for the glibc project.
Re: Setup non-pushing gerrit instance for glibc.
On 2019-10-25 12:10 p.m., Joseph Myers wrote:
>>> There is a difference of *intent* between changes that depend on one
>>> another and a patch series. A patch series is saying:
>>> * there is a common purpose motivating the patches; and
>> In Gerrit, you'd probably use topics to indicate that many changes have
>> a common purpose (whether they are interdependent or not).
> If using a topic were to mark the patches as a patch series (including
> marking email subjects and threading them accordingly), that would be
> fine. I don't think it's necessary for simply pushing multiple changes at
> once to be the way you cause something to be handled as a patch series, if
> topics are the idiomatic concept in gerrit that corresponds to a patch
> series as generated by git-format-patch.
I don't believe the topic is included in the email (at least not the subject),
but that is likely possible to do. For example, including it in the prefix tag:
I think that would help, but we would still be missing the information about
the order of the patches. Any ideas for that?
>>> There's also the variant of patch series that are explained in the cover
>>> letter (or in other text not intended for the final commit) as being split
>>> only for review purposes and intended to be squashed for commit, if the
>>> pieces most convenient for review don't form bisectable commits. I'm not
>>> sure how much any review system needs to know about the distinction
>>> between the two kinds of patch series if it's not pushing the commits
>> I don't think there would be a problem with that, except that the two emails
>> on the mailing would not be threaded together. More thoughts about that
> Well, there would be issues if you wanted gerrit to push changes itself.
> And how does the "identify this as being the same change" system (for
> knowing when something has been committed) work if multiple separately
> reviewed patches are squashed into one commit?
In that case, I would keep in the squashed commit the Change-Id of the first
commit (i.e. the commit that contains the logical change, not the generated
stuff). When pushing that commit, it will auto-close the first change. The
last/final version of that change would therefore be the full thing, including
the generated stuff.
I would then need to abandon the second commit. In the reason field (when you
click Abandon) I would say that since the content has been squashed in the
parent change, which is now merged, this one is no longer needed.
> (Is the valid syntax for Change-Ids documented anywhere? In particular,
> is it OK to write a human-readable Change-Id oneself?)
It's not mentioned here  so I suppose it's not documented. We would have
to look in the source code (or just try it) to see what's supported.