Re: [hackers] [st][PATCH] Make config.h depend on config.def.h

From: Bob Uhl <buhl_AT_zvelo.com>
Date: Fri, 02 Dec 2016 13:53:20 -0700

Laslo Hunhold <dev_AT_frign.de> writes:
>
>> How come? At least in my own workflow, I've been surprised by an
>> uncopied config.h repeatedly. My expectation is that if I change a
>> source file (e.g. config.def.h) that config.h will be updated.
>
> config.def.h contains the default settings. Of course you can change
> the defaults, but from a general perspective, it should remain
> unchanged.

…

> Yes that's exactly the point. If I have a git-repo and a nice,
> fine-tuned config.h and do a git pull that pulls in config.def.h
> changes. When I run make, my config.def is overwritten and lost
> forever. This sucks.

Ah, I guess that's where my workflow has been different: from my POV
customisations to config(.def)?.h are just like personal patches one
makes to the rest of the source code: something I have to manage when I
merge from upstream. E.g. if I added the clipboard or scrollback
patches locally, then pull down from upstream then there's a chance that
updates will require me to do some maintenance. In the case of
config(.def)?.h, it's likely that the places where changes occur are
well-enough isolated that merging maintenance is un-needed (git's pretty
good at that).

I'm not asserting that my workflow is superior, just noting why it's
different. I'm honestly surprised that folks edit config.h, although
reading the st homepage it does appear that's the intended way to do it.
For whatever reason, I hadn't noticed that way back when I first started
using the suckless tools: I've been maintaining my changes in
config.def.h all this time.

I do think the nice thing about the way I've been doing things is that
it's _really_ easy to merge upstream config.def.h changes in (basically
automatic); the negative side of that is that in order to get clean
commits for non-config changes I have to branch off of upstream/master.
Another benefit is that I'm able to maintain a checked-in version of my
changes, rather than keeping them in a non-version-controlled file,
although some might wonder if it's really necessary to track changes to
text colours:-)

Anyway, consider the patch withdrawn. If folks are maintaining their
changes in config.h then it's obviously a terrible idea to obliterate
it. I wouldn't submit a patch that I think makes things worse for
folks.

Bob Uhl
Received on Fri Dec 02 2016 - 21:53:20 CET