Re: [Possible phishing attempt] [dev] newbie questions: config*.h; patches

From: Mick Phillips <suckless_AT_ecdysis.zsczr.com>
Date: Sun, 22 Sep 2024 22:33:17 +0000

Hey there,

> config*.h:
>
> so far, i've been either staying on master, or my personal branch `mine`
> branch, and copying config.def.h to config.h (or, letting Makefile do
> that). then, editing config.h to my heart's content, running make, etc.
>
> that's worked okay.
>
> but, given git (i guess), i sort of wonder if what i might do is switch
> to branch `mine`, edit on config.def.h, hand copy that to config.h?
> (well, maybe add, in the version of Makefile in `mine`, a dependency on
> config.def.h for the config.h target.)

I've been using suckless for many years. This is the workflow I have settled on:

* Create a new branch for each version.
* In my branch for a version, I work directly on `config.h` and commit those changes, as well as making commits for any other patches I want.
* When a new version comes out, cherry pick all my personal configs and patches from the previous version branch to the new version branch. `git log --cherry 0.1.0...mine/0.1.0` can help with remembering which commits are mine, using some version tag 0.1.0 as an example.

Sometimes this workflow means needing to manually resolve a merge conflict or update my configs/patches to adapt to changes in the upstream code. However, it doesn't happen very often. Sometimes it means carrying a new commit which reverts an upstream commit, if they introduced something I don't like.

If I want to try a new patch, I'll usually create a new branch just for that patch, based on the same commit that the patch is based on. Then I can cherry-pick it over to my personal version branches. If that gets too complicated, such as it's an old patch and too much stuff breaks due to intervening changes, I'll try cherry-picking it into one new version branch at a time until it can finally come into the latest version.

I used to have a workflow where I kept all my patches as actual patch files in a repo outside the upstream clone, and applied the patches manually using a build script. But then I got more confident with Git and realized I might as well use branching and cherry-picking to keep everything together. I add a second remote to hold my fork, alongside the upstream remote for pulling new versions in.
Received on Mon Sep 23 2024 - 00:33:17 CEST