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
> <seg...@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?)
Segher
