Replacing USE_GCC=any and the danfe@ filter (was: svn commit: r568012 - head/net/tightvnc)

[Michael Gmelin]

On Thu, 3 Jun 2021 12:11:57 +0200
Mathieu Arnold <mat at freebsd.org> wrote:

> On Thu, Jun 03, 2021 at 11:50:54AM +0200, Torsten Zuehlsdorff wrote:
> > 
> > 
> > On 03.06.21 08:32, Mathieu Arnold wrote:  
> > > On Thu, Jun 03, 2021 at 12:22:47AM +0200, Gerald Pfeifer wrote:  
> > > > On Sun, 30 May 2021, Mathieu Arnold wrote:  
> > > > > Thank you for working on this.  
> > > > 
> > > > So, I was just ready to commit the next step and prepared a
> > > > nice git style commit message:
> > > > 
> > > >     Replace USE_GCC=any with USE_GCC=yes
> > > >     USE_GCC=any has been equivalent to USE_GCC=yes in most
> > > > cases (such as i386 and amd64 since 12.x and depending on
> > > > configuration 11.x, most newer installations on other
> > > > platforms, and 13.x across the board).
> > > >     Since commit 96c17633d90386b5bcf8 Mk/bsd.gcc.mk ...
> > > > 
> > > > Alas, the danfe@ filter struck:
> > > > 
> > > >     remote: Resolving deltas: 100% (111/111), completed with
> > > > 111 local objects. remote:
> > > >     remote:
> > > > ================================================================
> > > > remote: First line does not start with the regular remote:
> > > > category/port: subject remote:
> > > > ================================================================
> > > > 
> > > > What now?
> > > > 
> > > > Neither "*/*: Replace USE_GCC=any..." in the subject nor a
> > > > couple dozen individual commits strike me as desirable.  
> > > 
> > > *: Replace... works just fine.  
> > 
> > This seems to be a transcription of "It works around a rule which
> > has its purpose but should not be enforced 100% of the time".  
> 
> Well, no, the subject of all commits has to have a "discriminator" to
> tell people scanning commits what a commit is about.
> 
> Having '*:' or '*/*:' for commits that span many ports is also fine,
> it does not defeats the rule, it acts as the discriminator saying
> that it's not about a specific port, but a change, like a framework
> sweep.

Will

  cat1/port1, cat2/port2: Update to xyz

still work though?

If they are completely unrelated, I would assume that doing multiple
commits is always preferred.

But I'm thinking about ports that depend on each other, or even
those using MASTERDIR, where there simply won't be a second
commit. Example:

devel/arcanist uses devel/arcanist-lib, so to upgrade both, only
devel/arcanist-lib/* is modified.

I would like to use this commit title:

  devel/arcanist, devel/arcanist-lib: Update to 2021-06-03

Will that pass?

Thanks
Michael

-- 
Michael Gmelin