Git ChangeLog policy for GCC Testsuite inquiry

[Richard Earnshaw (lists)]

On 07/02/2020 13:48, Segher Boessenkool wrote:
> Hi!
> 
> On Fri, Feb 07, 2020 at 10:19:56AM +0100, Richard Biener wrote:
>> On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool
>> <segher@kernel.crashing.org> wrote:
>>> Yeah, don't look at me then :-)
>>>
>>> I *like* having most of those steps, most of this should only be done by
>>> people who are awake.
>>>
>>>> it's definitely a part that requires
>>>> more typing compared to svn.
>>>
>>> Instead of "git am" I had "patch -p1 <", distributing the changelog parts
>>> I just did in vi (as with git), then "svn ci", which pick up all modified
>>> files directly (sometimes an "svn add" first).  It's pretty much the same
>>> for me.
>>
>> I'm a believer on committing from the tree I actually tested,
> 
> But you cannot.  Depending on which machine I use, a regstrap (all
> languages) is between 2h and 40m, so when you push it upstream there
> will usually be commits by other people as well.
> 
> I also test just master plus what I want to commit, which works fine
> most of the time.  The master you test with is older than the one you
> commit to (and yes, this sometimes matters :-/ ).
> 
>> so it
>> was with SVN: patch, test, svn up, edit changelogs (cut&paste from the
>> patch header), svn diff | less (check wha'ts abotu to be committed), svn commit
>> with GIT its now: patch, test, git add/commit, git pull --rebase, edit
>> changelogs
>> (cut&paste from the patch header), git commit --amend, git push -n -v,
>> git show <what's pushed>, git push
>>
>> So I wonder to "optimize" this somewhat.
> 
> Having the patch as a file instead of just as a git commit makes the
> cut-and-paste step a little easier (and more reliable).
> 
> Once you have done this many many times, you can skip some of the
> verification steps because you just *know* the state of everything.  So
> things will be a little faster over time, or at least it will feel that
> way.
> 
> Handling the changelog as you want will make things more streamlined,
> certainly.  It also makes it easier to mess things up...  We'll see what
> will happen, I guess :-)
> 
>>>> ChangeLog file populating could be even
>>>> done on the server-side I guess (and not appropriately formatted logs
>>>> for the extraction/moving process rejected).
>>>
>>> Yup.  As long as it's fool-proof, and we have some way to correct small
>>> disasters (both of those!)
>>
>> I'd definitely prefer server-side operation, and yes, that "script" looking
>> at the commit would need to have a "extract changelog parts" part
>> for a pre-accept hook and the actual part amending the commit with
>> the changelog file changes (not sure if that's even possible in a hook?).
> 
> If you can think of it, it is possible.  It's not even too hard I think.
> 
> You want the commit hook to actually populate the changelog files, which
> are still normal checked-in files, aha!  That's a great idea.  That
> completely gets rid of my "fix mistakes" worries, and it will probably
> also get rid of the "yet another flag day" inconvenience.
> 
>> Fixing mistakes in the ChangeLog files could be as easy as allowing
>> changes to ChangeLog files without that magic.
> 
> Yeah :-)
> 
>> Anyway, I hope to put sth together with bash & [g]awk
> 
> gl;hf
> 
> 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.

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.

R.

> 
> 
> Segher
>