Re: [dev] new pre-patched version of dwm available

From: Eric Pruitt <eric.pruitt_AT_gmail.com>
Date: Sun, 31 Jul 2016 23:18:06 -0700

On Sun, Jul 31, 2016 at 08:26:36AM +0200, Jan Christoph Ebersbach wrote:
> Have you tried to increase patch's fuzz factor with the --fuzz option in
> order to achieve the same result?

I messed tried messing with the fuzzing factor, but I had some patches
apply in wrong place. I am not certain because it's been a while since I
tried this, but I want to say the problem was generally caused by code
that's often repeated e.g. for loops for counting windows or iterating
over monitors. I just ran dwm.c through "sort | uniq -c | sort -n," and
"for (m = mons; m; m = m->next)" appears at least 6 times.

> I never used the rebase model described in the customization section.
> Since you know both ways, why did you switch to patch files?

I've actually tried three approaches: (1) the rebase my own tree onto
the suckless one, (2) patches alongside the dwm source code and my
current approach which is (3) patches completely divorced from the dwm
repository. With the first two approaches, I found dealing with
patch-breaking updates far too tedious especially when patches were
dependent on one another. My config.mk also differed from the suckless
one, so I generally had to review it and manually adjust the
corresponding flags in my file. There are several things I like about
using patches and an external dwm repository, but some this also applies
to (2):

- When dwm gets updated, I can work on one patch at a time in almost any
  order (of my 16 dwm patches, only 2 have dependencies while the
  remaining 14 can be applied with or without the other).

- Because of how my build system works, I can temporarily disable a
  patch by simply renaming it from *.diff to something like *.diff.x
  because the Makfile target only globs for *.diff. I often use vidir
  (https://joeyh.name/code/moreutils/) to do this with multiple patches.

- Similarly, if I want to discard a patch because I don't use it or the
  functionality has been accepted upstream, I don't have to use "git
  revert" and hunt for all changes related to a specific feature and
  hope there are no dependency issues. Instead, I just "git rm" the diff
  file and call it a day.

Eric

Received on Mon Aug 01 2016 - 08:18:06 CEST

This archive was generated by hypermail 2.3.0 : Mon Aug 01 2016 - 08:24:11 CEST