Hi Takashi,
On Thu, 18 Dec 2025, Takashi Yano wrote:
> On Wed, 17 Dec 2025 15:55:58 +0100 (CET)
> Johannes Schindelin wrote:
>
> > On Wed, 17 Dec 2025, Takashi Yano wrote:
> >
> > > Fixes: f74dc93c6359 ("fix native symlink spawn passing wrong arg0")
> > > Reviewed-by: Johannes Schindelin <[email protected]>
> > > Signed-off-by: Takashi Yano <[email protected]>
> > > ---
> > > winsup/cygwin/fhandler/termios.cc | 21 ++++++++++++++++-----
> > > winsup/cygwin/local_includes/fhandler.h | 2 +-
> > > winsup/cygwin/spawn.cc | 2 +-
> > > 3 files changed, 18 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/winsup/cygwin/fhandler/termios.cc
> > > b/winsup/cygwin/fhandler/termios.cc
> > > index 19d6220bc..7fdbf6a97 100644
> > > --- a/winsup/cygwin/fhandler/termios.cc
> > > +++ b/winsup/cygwin/fhandler/termios.cc
> > > @@ -702,10 +702,21 @@ fhandler_termios::fstat (struct stat *buf)
> > > }
> > >
> > > static bool
> > > -is_console_app (const WCHAR *filename)
> > > +is_console_app (path_conv &pc)
> >
> > I see you insist of mixing the refactor where `path_conv &` is passed
> > instead of `WCHAR *` with the actual fix.
> >
> > Not a fan. I regularly hit your commits when bisecting Cygwin runtime
> > regressions, and I have not yet learned to be okay with finding patches
> > that do too many things at the same time.
>
> Do you mean there should be a separate patch which just change
> the argument WCHAR * to path_conv & before the acutual fix?
> Doesn't that make the intent of the first commit unclear?
The first commit just needs a clear commit message that conveys the
intention. Then everything becomes a lot better. For example, `git bisect`
would become more efficient because it wouldn't find a commit that does
several things at the same time (refactoring and working around an API
limitation), but would instead find a commit that does one thing. I have
spent enough time bisecting Cygwin breakages to know how much of a time
saver that is, let alone a morale booster.
> > I'm weven less a fan of the non-descriptive variable name `pc` which
> > unnecessarily increases cognitive load.
> >
> > But hey, rather than shouting my objections to the form in the void, I'll
> > just accept that my recommendations are not welcome,
>
> ??? I don't understand why you think so. Which recommendations you mean?
I regularly suggest to you to spend more love on the commit messages so
that they become more useful than they are now.
Don't get me wrong, I have nothing against being concise. I have something
against being incomplete. The commit message that is proposed here only
makes sense to somebody who just investigated the bug, in depth. Anybody
who hasn't poured over the code for a substantial amount of time will be
confounded by the provided explanation. I have been in this situation with
your commit messages on more occasions than I care to remember, and I am
not exactly what one would call a novice software engineer. Granted, your
commit messages are way, way better than, say, commit messages like this:
https://github.com/evcc-io/evcc/commit/258bd9e1f550. But I seriously long
for the commit message to provide the four pillars of a good message (see
https://github.blog/developer-skills/github/write-better-commits-build-better-projects/):
Intent, Context, Implementation and Justification. I want to understand
what is going on after reading the commit message, not be sent on a crazy
goose chase.
Maybe I should find an analogy to illustrate the problem. Have a look at
https://www.youtube.com/watch?v=lDSbg-1y5UY. It is an exquisitely funny
and concise summary of the movie "Frozen". But if you don't know the movie
before watching Olaf recount the story, you understand precisely nothing.
It's not "concise", it's "too incomplete".
Commit messages are not a diary. They are messages you send to software
engineers who need to work with your changes. Sometimes, they are even
messages to your future self.
This is particularly important in the context of bug fixing. As I have
debugged Cygwin bugs quite often in the past, I can tell you that it is
quite frustrating to end up finding commits that leave everything unclear,
whose diffs are too large to find any obvious bugs. There are no obvious
bugs. There are only the non-obvious, hard to track down ones. This is the
kind of frustration I aim to avoid by telling you how I want you to
improve the commits. This is my attempt to turn that frustration into an
outcome worth having.
Ciao,
Johannes
>
> > and this is the shape
> > of the patch that you want to have. It does fix the bug, so that's good.
>
> --
> Takashi Yano <[email protected]>
>
