Hi Jonas,
I have rebased the series on top of your upstream/debian/latest, so the
structural debian/copyright fixes you already cherry-picked are no
longer part of my copyright update commit.
I also reworked update-highlight-core along the lines you suggested. The
generated .mrconfig now uses a DEFAULT clone helper with --depth=1, the
read loops no longer contain a literal TAB character, and the tar
pipeline plus find -exec sh -c cleanup has been replaced with find ...
-delete.
I have left the source-package split out of this revision for now, since
that seems like a larger packaging decision and I would prefer not to
preempt your preference there without confirmation.
Best,
Junyong Liang
On 2026/5/18 15:46, Jonas Smedegaard wrote:
Quoting Junyong Liang (2026-05-17 18:05:47)
I’ve made another round of updates based on your suggestions for the
maintenance tooling migration. In particular, I’ve moved the setup to
use myrepos, replaced the update script with a shell-based version,
and split the changes into clearer, easier-to-review commits.
The updated version builds successfully on my machine. Could you
please take another look at my fork when you have a chance?
This one feels much easier to read for me. Thanks for doing that
restructuring!
You still lump multiple independent changes together in each git
commit - as a concrete example, I noticed that in the commit updating
debian/copyright you also corrected some structural bugs in the
existing content. I have now cherry-picked those changes and applied
them to the main branch - crediting you :-)
It seems update-highlight-core use tar to remove files. I would use
`find "$src" ... -delete` for that, but maybe I am missing some subtle
tricks there - if so, I recommend adding a comment hinting at that the
reason for the choice of tooling there. Simplifying there would also
avoid piping into `-exec sh -c` - I am aware that some patterns are
safe, but even then I worry about accidentally making a clumsy edit
later that turns it unsafe.
If I understand correctly, you clone and then drop the .git database.
Assuming that's correctly understood, then a shallow clone should be
adequate - i.e. add `--depth=1` to the clone command.
The .mrconfig file can be more compact by adding a default function:
```
[DEFAULT]
lib=clone () { git clone --quiet --filter=blob:none --depth=1 $1 $2 }
[.work/rust]
checkout = clone https://github.com/tree-sitter/tree-sitter-rust rust
```
You use TAB as field separator. I am a fan of TAB, so I am not gonna
try to dissuade you from doing that, but since many editors have a hard
time even visualizing TAB as a raw character, I think it is best to
limit that: in update-highlight-core you could instead use `IFS=$'\t'`.
The cloned code is more than 1GB, where the code of helix itself is
less than 200MB. I would prefer that this was maintained as a separate
source package, build-depending on hx or if needed on a new hx-devel
providing the subset of sources needed for these new routines to work.
What do you think?
- Jonas
