This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Fri, Feb 7, 2020 at 4:43 PM Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 07/02/2020 15:32, Segher Boessenkool wrote:
> > On Fri, Feb 07, 2020 at 01:56:08PM +0000, Richard Earnshaw (lists) wrote:
> >> On 07/02/2020 13:48, Segher Boessenkool wrote:
> >>> Should we require some simple markup in the commit message before the
> >>> changelogs? Maybe
> >>>
> >>> CL gcc/
> >>> * blablalba etc.
> >>> CL gcc/testsuite/
> >>> * gcc.target/...
> >>
> >>> etc.
> >>>
> >>> (Dunno if just "^CL " is too short?)
> >>
> >> I was thinking "@CL <dir>", but ^CL would work just as well.
> >
> > I meant ^ as in a regular expression, sorry for not being clear.
>
> Ah! I think something more syntactically explicit would help avoid the
> risk of mis-parsing.
One just has to err on the side of rejection ... sofar I've tried to start
matching at ^20 (the date line) until the last ^\tPR line (multiple
PR foo/12345 lines) then the actual ChangeLog file entries are
separated by blank likes where there's unwritten policy to
prepend those with ^\tDIR/ where DIR is for example cp (implicitely
inside gcc) or libgomp (toplevel). There's easy enough heuristics
to detect the gcc/ and gcc/testsuite case which is most often
omitted (just see where the first mentioned file lives in).
That said, doing the parsing is reasonably easy but the question
is the execution environment of the git hook - does the script have
access to an actual checkout? I guess not (so much for file
existance tests), but then how to amend the commit with new
file changes?
And yes, the idea was to keep the status quo (checked in and
updated ChangeLog files) but have the convenience of not manually
updating them. And indeed that makes a transition to a post ChangeLog
file world easy.
Richard.
> >
> >> Any script should, in addition to extracting the author and email also
> >> grep for "Co-authored-by:" annotations and add those as additional
> >> contributors, of course.
> >
> > Is there no existing established practice for that? (Or is this it and
> > so infrquent that I never have seen it :-) )
> >
> >
>
> It's a convention (much like signed-off-by, etc). But it's fairly
> widely accepted. In the git conversion we added fields for it where we
> detected co-authorship in the ChangeLog entries. Git has no specific
> field for recording additional authors, so this approach addresses this
> and some tools know how to add the appropriate accreditation based on it.
>
> https://git.wiki.kernel.org/index.php/CommitMessageConventions
>
> Also "git help interpret-trailers"
>
> R.
>
>
> > Segher
> >
>