1 |
On Thu, May 30, 2019 at 7:58 AM Mick <michaelkintzios@×××××.com> wrote: |
2 |
> |
3 |
> There's also cfg-update and there may be more tools to manage changes in |
4 |
> config files following an update. |
5 |
> |
6 |
> The merge function is particularly useful, because you can see where your |
7 |
> edits are/not affected by any changes to the new config defaults and reject/ |
8 |
> accept one change at a time. |
9 |
|
10 |
Yeah, I couldn't live without cfg-update, especially with the |
11 |
auto-merging of changes. The one caveat is that it isn't the |
12 |
best-maintained piece of software out there. I'm mostly nursing it |
13 |
along. |
14 |
|
15 |
It uses 3-way diffs, which means you're looking at the new file, the |
16 |
last Gentoo-provided file, and your current file. So, you can easily |
17 |
see what changed upstream in the last update and focus on those |
18 |
changes, vs the stuff that you added. |
19 |
|
20 |
It can do automatic 3-way diffs. This means that if you made a change |
21 |
to line 500 of some config file from the upstream one, and in the new |
22 |
version line 3 changes, then line 3 will get updated without any |
23 |
intervention. If on the other hand a line close to line 500 changes |
24 |
then you'll be prompted to merge the changes. This is of course |
25 |
optional behavior, but 99% of the time it does the right thing, since |
26 |
most use default configs with a few tweaks. If you completely |
27 |
scrapped the upstream config file and wrote your own this feature |
28 |
won't be useful, but then again it won't touch the files anyway since |
29 |
it will see that it changed. |
30 |
|
31 |
It also tracks everything in RCS. Not my favorite vcs but it works |
32 |
well enough for what the tool itself does, and I just keep all of /etc |
33 |
in git which is the history I'd look at. I use etckeeper (in the |
34 |
repo) for this - nothing too fancy - just some portage hooks to keep |
35 |
git up to date for etc. |
36 |
|
37 |
-- |
38 |
Rich |