Gitk on wide displays

 Gitk on wide displays

This is the original layout of gitk:

 I realized (years ago) that competing for height, while there is abundant space to the sides  is bad.

 

It's better to keep "lists" to the side, while the main diff pane should use the full height.

 

 the changes are in gitk-wide branch

Second 4 months of Rust

Macros

CLAP

Using Clippy

Std...

Reading the pages .....traits defined, Enums, Structs .... and (generic) definitions of the trait for EXTERNAL types. That's why it's listed there, not in the page of those types.

 

Any .....using 

 intrinsics::type_id::<T>()

HashMap ...

 Tricking the HashMap | Ivan Dubrov 

 

!Sized

Generics parameters implicitly constrained to Sized

 

- iterators

-  

Error handling

Option -> Result

std::Result

? expands to ..... return Err(From::from(e)) 

Defining new error types out of lower-level ones:

YT: Mastering Error Handling in Rust: From Panics to thiserror & anyhow | with Nathan Stocks

#[non_exhaustive]

thiserror   -> 

 

#[derive(Error)]

      #[error("message")] 

      ....#[from:] ... 

 

and we can use  derive_more::Error 

Error trait enables the nesting: 

• source()
• provide()   default to None, but can be implemented   

  

YT: A Simpler Way to See Results

 

Anyhow:

https://docs.rs/anyhow/latest/anyhow/index.html

thiserror:  derive macro to have custom error and transformation from other Error types.

Clarifying references with  Claude.io:

https://doc.rust-lang.org/std/primitive.reference.html

Prompts:

Rust references implement all certain traits Copy, Clone etc ..... is it because those traits have only &self methods?
.....  
Yes,true. Those specific Traits are implemented by the definition/semantics of References.  What I meant is the other Traits which .... references having Deref... when implemented for T and containing only &self methods, are therefore implemented for &T.  Or is there anything more profound on that?

Now I know:

Learning Rust in 4 months

I'm through a break from jobs.

May - August I studied Rust, mostly with videos.

 

1st month 

* https://rust-book.cs.brown.edu/ the edition with quizzes

Single chapters are also explained in videos, I used it for the advanced topics as intro, since it's quick.

 

* intro for C++ 

 

*  Intro to significant features:

 

 

* Significant traits.  Into/From/AsRef...

 

2nd month

*  Introduction to Async, Tokio

 

*  The fine point of lifetime specification...

 

* Meticulous lifetimes explanation.

Because certain videos stress the relationship of *input* lifetimes with the output ones, but here it's shown how the input lifetimes can be tied between themselves (as constraints). 

 

 

 * further:

Book of books:  

https://lborb.github.io/book/unofficial.html 

 

 

Starting to port Forking keyboard driver to Windows

Introduction

 After 20 years of developing a "forking" keyboard driver for Xfree86/Xorg, I decided to finally attempt to make it available on Windows. 

 As a first step I split the code into portable core, and the interfacing glue for Xorg.  In a couple of days I implemented such a glue for the "libinput" to be used in Weston (Wayland).

Plan for Windows

Encouraged by the speedy adaptation, I started to assemble the tools for Windows:

1.  wdk
2.  visual studio
3.  a "target" machine (KVM+Qemu  running Windows). 

Requirements for 3. included public IP for the guest VM (ping should be possible).

virt-install --name win11 --cdrom Win11_24H2_EnglishInternational_x64.iso 

virt-viewer win11

Host machine setup

Installing VS was easy, and included a misleadingly named "wdk-extension" which did not include WDK itself. So  ntddk.h header was missing during the first builds.      Installing WDK properly solved that.

Target machine

Regarding  preparation ... just re-read and execute correctly the steps.

I didn't install any SDK or VStudio on the target PC! Only the WDK.

For "non-enhanced mode" ....I didn't do anything with my KVM/Qemu setup.

WDK Test Target Setup MSI ... indeed provided by WDK. (If by chance you install SDK, you will find other MSI files but those are irrelevant.)

Provisioning made inside VS (on the host) ... sometimes fails. Repeating can fix it.

This create the WDKRemoteUser account (on the target) and logs as it. On one physical machine I couldn't login as it has an unknown password.

Deploying

I started to try-out Sample drivers. In particular the kbfilter. Deploy failed.

• one can see the XML logs... one has to understand that  "Driver Test Group Explorer" tab is sibling of "Git Changes" and "Solution Explorer".
• Or you can make a video of the terminals opened on the target -- they disappear quickly.
  

The message is the same in both "Cannot create a stable subkey under a volatile parent key". Other failures could be present too.

So re-read the Readme and the INF file template

- Set the hardware ID in the inx file

I didn't see any 

> WdfCoinstaller010xx.dll The coinstaller for version 1.xx of KMDF.

Manual build

Using MSBuild ... does work, but does not help with the deployment.

 Manual deployment

So, while searching for solutions of the aforementioned issues I learned:

* dbgview  seems similar to dmesg of linux. But it crashes sometimes (disappears). How to see messages during the boot?
To see kernel message it must be run "as administrator" !

* devcon tool -- mysterious tool installed during the provisioning (by VS)

https://github.com/hawku/TabletDriver/issues/225

I looked at the github issues of the sample drivers -- for example:

about devcon install.

* regedit  .... indeed ... there is a key which is crucial:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}\UpperFilters

But beware .... the format while editing is ..... one item per line

"kbdclass kbfilter" .... this indeed makes it work !!!

Wrong value and you lose keyboard !!!!!

* devmgr one can observe, manually remove.

So, what works?

deploy (from VS). Then  just "Update" the driver of the PS/2 keyboard device...

if it says "Already up-to-date" then your HW-id is wrong!!! So update the *inf with correct value.

and Registry -- irrelevant.

WdfDriverCreate was failing with 0xC000009A so disable the verification.

Story of abandoning own tool in favour of learning multiple projects and combining them

Adopting Debian Installer  (time scale)

In 2016 I started to formalize the way I want to replicate my debian installation on other PCs. I think I needed that once per year.

That is indicated by git commits of a repo with numbered scripts -- stages of installing debian & my expected packages & modifications, after booting with a usb flash drive.

Disk-partitioning was hard (shrinking Windows partitions), configuring apt also forever evolving.

Prior to that I would have just reattach the disks and copied the filesystem.

After 6 years, in 2022 (having used those tools about 10 times) I started to suspect I could spend my time better by learning & fixing a publicly developed tool.

And indeed in April 2023 I tried out the debian-installer (the "hd-media" option), with some pre-seeding.

Then I needed more than pre-seed & targeting unstable/SID: I wanted to understand all possible disk encryption setups, and using my additional apt repository (+ apt configuration).

Experiments

So, I was using the build system in debian-installer (to build customizations) and decided to use a virtual PC (KVM-qemu) to quickly test the result.

I had to overcome bug 940801

I could test the partitioning with encryption on a virtual disk (10GB).

• Started to wonder about having "udeb" packages in my reprepro.
• Not really sure what is inside "mini.iso", maybe all is inside the initrd?

Setting up PXE

I wanted to also avoid using flash drives/sd-cards  -- using PXE seems more elegant. Also using netboot rather than hd-media seems a nice simplification.

But there's a catch: this requires modifying DHCP server (which I cannot do on my main modem/route), and I didn't want to set a separate dhcp just for this use-case (on a linux box, with the only connection to the booting PC).

Anyway, I started still with KVM -- a new "bridge" with dhcp pointing at local tftp.

I had to use signed grub to boot with secure-boot.

Going for physical PC

So I installed dd-wrt on another router/wifi access point, and detached from its "bridge" between all LAN connectors one connector which is then serviced by a new dhcp server, and advertises the necessary option for PXE boot.

 

First successful run

I included a custom udeb: I needed a modified "choose-mirror" to debug still flaky pre-seed configuration of the net interface.

Partitioning seems intuitive (once you want to use the same key for both Swap & Root fs).

Choose the minimal (ssh server, standard), and after the reboot  do still some manual copying, apt configuration, and finally install my  "top" virtual packages.

логическая загадка

Есть 5 космических кораблей (из разных стран мира). У каждого есть номер (1-5), цвет, маскот и каждый привозит сувенир из Луны. Они не стартуют в своей стране но приземляются в ней.  Нам известны следующие факты: 

 

1. Синий корабль стартует в Хирошиме (Япония)
2. Русский корабль привезёт с Луны "флаг США" (как сувенир) 
3. В Люнбурге (в каком же государстве ... дочитать до конца и узнаешь) стартует корабль номер 1. 
4. Кошка путешествует в корабле с номером на 1 меньше чем номер золотого корабля. 
5. Соловей является маскотом корабля, с номером на 1 больше чем у зелёного корабля. 
6. Корабль со средним номером привозит "лунарный пыл" (как сувенир). 
7. Улитка маскот корабля, который стартует на Байконуре (будем считать городом в России). 
8. Корабль который стартовал на мысе Каневерале (США) привезет "старую лунарную камеру" (=сувенир). 
9. Маскотом на красном корабле является жаба. 
10. Зелённый корабль принадлежит Китае. 
11. У Японии номер 2. 
12. Серебристый корабль принадлежит Германии. 
13. Корабль США стартует в Пекинге. 
14. Германия привезёт в Люнбург с Луны "космическоя авто" и имеет номер на 1 меньше чем Россия. 
    

 

Вся эта информация хватит для того, чтобы ответить на следующие 2 вопроса:

1. A. Который корабль имеет зебру как маскота? 
2. B. Который корабль привезёт "женшину" как сувенир?
   

 Working on Proof-of-concept

Based on my git segments/sums, I can construct a 

poset of modifications (micro-features), and 

study them in isolation. For the whole-picture study I use (modified) xdot with an extension to handle "gitk://" actions, so I can open gitk (restricted to the segment history) by clicking on single nodes:

git-hierarchy contains the "git-graph -x" command to open such a graph.

Keeping up with debian Sid

My small build system

I need to replace some distro packages with my improvements.

For this I need to patch the sources -- I only handle git. I need to be notified, warned, when a new version is needed.

So I patched apt to report when a switch from my version to the upstream would happen (due to  "apt dist-upgrade").

In such a case I run my  git-rebase-origin which rebases my feature poset (of feature branches/segments mixed into "merges") over a refreshed remote branch.

Then I run my scripts to invoke gbp(1) with a suitable version string, and create the deb packages & put them in reprepro.

the sequence of commands to maintain apt itself:


$ cd ~/git/apt/
$ git-rebase-origin  
# this deduces the upstream -- base of my feature branches.

$ release
# this detects I'm building my extension of upstream debian package, so deduces the correct version, build, uploads, tags, pushes, installs.

When I only want to test some changes, I run 

$ snap

which creates a .deb package, installs it, withouth any reprepro etc.

Logický test

5 lodí, každá má číslo, barvu, maskota a suvenýr z Měsíce.
Nestartují ze své země, ale přistávají v ní.

1. Modrá loď startuje v Hirošimě
2. SSSR přiveze z Měsíce vlajku USA
3. v Lunburgu startuje loď s číslem 1.
4. Kočka cestuje v lodi s číslem o 1 menším než je číslo zlaté lodi.
5 Slavík je maskotem lodi, jejíž start. číslo je o 1 vyšší než číslo zelené lodi.
6 Loď s prostředním číslem veze zpět měsíční prach.
7 Hlemýžd je maskot lodi, jež startuje na Bajkonuru.
8 Stát, který odstartoval na mysu Caneveral, příveze zpět starou měsíční kameru.
9 Maskot v červené lodi je žába.
10 Zelená loď patří Číně.
11 Japonsko má startovní číslo 2.
12 Stříbrná loď patří NSR.
13 Loď USA startuje v Pekingu.
14 NSR přiveze do Lunburgu z měsíce kosmické auto a má startovní číslo o 1 nižší než SSSR.


Tyto infomace stačí k tomu, abychom zodpověděli dvě otázky:

A. Která loď má jako maskota zebru?
B. Která loď přiveze zpět z měsíce ženu?

Upgrading Nubia 7 mini

I recently bought this  phone on marktplaats, already upgraded to Mokee Android 7. I liked the features, my previous phone used Android 4.2.
So I bought another one for my wife, this time I had to make the upgrade myself. It was not straightforward:

The first nubia used as recovery  TWRP 3.0.2-0, the other is with clockwork-mod (v6.0.5.0).

• I had to resize the big "grow" partition manually, i.e. merge it with "userdata".
• suddenly I saw disconnections of Wifi, and that was due to the same MAC address of the 2 nubias.

MAC address

So I searched for a solution to tune the MAC address. I found the hint on Intf0MacAddress in WCNSS_qcom_cfg.ini. But it did not work.

/data/misc/wifi/WCNSS_qcom_cfg.ini  nor  /system/etc/wifi/WCNSS_qcom_cfg.ini

So I had a workaround to

echo 98:6c:f5:63:ec:d0 > /sys/devices/fb000000.qcom,wcnss-wlan/wcnss_mac_addr

while in airplane mode.
In the end I  found /persist/WCNSS_qcom_cfg.ini which indeed works, and overrides the other 2 files.

ANDROID_SERIAL to distinguish them?

To have them accessible via adb at the same time, I need to distinguish by this serial number, which is unfortunately identical. For now I overwrite the kernel cmdline in img_info with "androidboot.serialno=XXX"

Proximity sensor

After receiving some (whatsapp) calls, I noticed it was almost impossible to get the screen back on, as expected.

So, as a workaround I turned off  in Phone> Settings> Accessibility> Use proximity sensor.

But Whatsapp does not seem to have this option.

So I installed Sensors test and some app to "reset/calibrate" but to no effect.

So I started to look for the kernel driver, to fix a possible bug. There are confusingly multiple kernel sources on github:

1. https://github.com/nx507j-dev/android_kernel_nubia_nx507j
2. https://github.com/ztemt/NX507J_5.1_kernel
3. https://github.com/MoKee/android_kernel_nubia_nx507j.git
4. https://github.com/MoKee/android_kernel_zte_nx507j.git

The 3rd is the one used on Mokee (my fixes in https://github.com/mmaruska/android_kernel_nubia_nx507j). The other ones fail when (Android) "init" configures (selinux) sepolicy.

Btw. failures of the other kernels can be seen thanks to android ram-console: after the failure, the phone reboots to recovery and 

adb shell cat /proc/last_kmsg

shows the problem.

In the end the problems is only the calibration, so 

 echo 500 > prox_threshold_low  

fixes the issue. To see this value, I did:

cd /sys/class/proximity/proximity/
echo 1 > prox_debug

and "dmesg -c" while running the sensor test app, to see:

[43580.286869] [SENSOR_ALS_PROX] [taos_prox_threshold_set: 2338] proxdata = 396

I guess it's stored in /persist/proxdata/threshold ?

Other issues

calendar/alarm database -- crash when entering the Alarm app:

android.database.sqlite.SQLiteException: Can't downgrade database from version 12 to 8

I removed the relevant file.

SystemUI crash due to wallpaper using too big image

java.lang.RuntimeException: Canvas: trying to draw too large(143769600bytes) bitmap.
....
AppCrashReceiver: com.android.systemui stopped unexpectedly...

rm  /data/system/user/0/wallpaper_*



My improvements (divided into feature-segments)  https://github.com/mmaruska/android_kernel_nubia_nx507j/network

Taming Android am command

In Android an intent can carry data of a certain mime type.
To test this feature, I had an App which sets up an IntentFilter, and then I would manually trigger it:

am broadcast -t text/xml -a my.action.START -d "file:///system/usr/share/mmc/settings.xml"

It did not work, so I had to read better about am options:

So I learned about FLAG_DEBUG_LOG_RESOLUTION (I also saw it in the sources). So I added "-t 8" as option.
Then I saw that the type used during the matching was Null, so I verified the binder transaction code:reading from binder tx data and writing tx data Here the writing:

ActivityManagerProxy
broadcastIntent()....
intent.writeToParcel(data, 0); // serializes the Intent
data.writeString(resolvedType); // separately adds the type

So the type has to be delivered separately, but am does not do it:

private void sendBroadcast() throws Exception {
Intent intent = makeIntent(UserHandle.USER_CURRENT);
IntentReceiver receiver = new IntentReceiver();
System.out.println("Broadcasting: " + intent);
// this is the fix null -> intent.getType()
mAm.broadcastIntent(null, intent, /* null */ intent.getType(), receiver, 0, null, null, mReceiverPermission,
android.app.AppOpsManager.OP_NONE, true, false, mUserId);
receiver.waitForFinish();
}

Building the Forking X server

Building the Forking X server

I work on Debian (Sid), so the Git repositories contain debian/ and  packages are built by git-buildpackage as documented in another post.

You can also install by using my debian repository:
deb http://www.ruska.it/~michal/reprepro sid main

I did not implement a new Extension - I extended the protocol of XKB.
So, first build the x11proto-kb-dev package

• https://github.com/mmaruska/x11proto-kb

Now it's possible to build both libX11 and the server:

• https://github.com/mmaruska/xserver

Since the ABI between the server and "input device" driver, it's necessary to recompile them. I use only evdev & synaptics. But, evdev is used for the keyboard, and I need precise timestamps, so there are changes, hence build from this repo:

• https://github.com/mmaruska/xserver-xorg-input-evdev

At this point the Xserver could be restarted. After building the X11 from:

• https://github.com/mmaruska/libX11.git
  
  one can start asking the X server about the active plugins. There is a tool for that:

•  https://github.com/mmaruska/xplugin

At this point it is possible to:

$ xinput list

....Virtual core keyboard                       id=3    [master keyboard (2)]

...

$  xplugin -l -d 3  

3 plugins in the pipeline

1: never-freeze-queue

2: xkb-auto-repeat

0: core

The function of each plugin:  

never-freeze-queue collects events while waiting for following plugins to proceed (& accept the events).  xkb-auto-repeat generates the auto-repeat events, core is the interface with dix/events.c.

Now we can finaly build the interesting feature: the "fork" plugin to be inserted before the auto-repeat plugin. It is implemented in C++ which explains some effort in the X server and x11proto-kb sources to make them C++ compatible.

So:

• https://github.com/mmaruska/fork-plugin   

so after building (& installing) you can insert that plugin:

$ xplugin -d 3 fork       # 3 is still the id of keyboard.
or also remove it:
$ xplugin -d 3 -fork

Now to activate some of the forks we need to communicate with that plugin, 

and build up a language to express the configuration.

• https://github.com/mmaruska/libfork

For the configuration language, I chose to use Scheme, in the Gauche implementation. So, one needs to install Gauche-dev, and build this binding module:

•   https://github.com/mmaruska/gauche-xlib

building that one is more involved (see my blog about building Gauche modules).

That packages contains my configuration to be used this way:

$ fork-config-mmc.scm 3

When trying to configure, keep in mind, that allocation of the "fork" keycodes

is possible only if the XKB Geometry allows it. I.e. keycodes not found on the Geometry will be used.

See in https://github.com/mmaruska/gauche-xlib/blob/master/bin/fork-config-mmc.scm how key "f" is used as Hyper modifier, or how Meta key acts as Escape key.

Forking -- multitouch on keyboard

Multitouch on keyboard is about ... interpreting simultaneous key presses
in a way that is different from sequential.

That is pressing 2 keys A+B should be something different from A, followed by B.
Years ago, I was told focus on the problem of converting one of the
letters into a modifier, and keep B as is. This has been enough of challenge to implement (properly), and I can share the software now.

The implementation includes patches to several components of the X-Windows system, and configuration tools.

Here's a diagram of involved parts:



The most complex part is extension of the Xorg server, to somehow postpone processing key events while maintaining the semantics of Un/Grab requests.

Since we use the timing of key events, we want to get best precision timestamps on them. Xorg server has to get the monotonic timestamp from the kernel/evdev.
That implies a bit of patches to input driver(xorg-evdev), and the DDX code to accepts events and put them into the event queue.

From there we want to plug this new functionality in the heap of machinery which implements auto-repeat, other XKB functionality, and then the Grab/Ungrab ops.

I have tried to separate, serialize the implementation of these functionalities, using this simple architecture: a linked list of  blocks with this API:
 (image missing)

These blocks pass Events  to the next one (in one direction), and in the other direction the information about Grab/Ungrab state is passed.

Indeed, if no event comes in, time can still be "pushed" through all these plugins,
so a plugin can also tell how early it is significant to push time to it.

(work-in-progress).

Hooks to adapt a notebook to different conditions

So, I use Ubuntu 12.04 on my notebook.

Here a list of (shell) hooks I implemented to make the system adapt to "the environment". Only the minimum relevant code

• Open/close lid -> internal screen on/off
  /etc/acpi/local/lid.sh.pre
  DISPLAY=:0
grep -q closed /proc/acpi/button/lid/*/state
xrandr -display $DISPLAY --output $internal --off

• When (un)docked -> external monitor on/off.  un/docking detected by AC online. No other way found (with Dell latitude e*)
  
  /etc/acpi/power.sh
  
  if [ $(cat /sys/class/power_supply/AC/online) = "1" ]; then
  DISPLAY=:0 xrandr --output DP-1 --auto --rotate left 
• Turn audio off/on  when on office network/at home:
  /etc/dhcp/dhclient-enter-hooks.d/  does not work with NM (see https://bugzilla.gnome.org/show_bug.cgi?id=709247 )
  So /etc/network/if-up.d/mute-in-office
  
   if [ ${DHCP4_DOMAIN_NAME-} = 'domain.name' ];
     amixer set Master mute
   elif [ ${CONNECTION_ID-} = "home-ssid" ];
          amixer set Master unmute
          amixer set Front unmute
          amixer set Headphone unmute
  
  
• prevent Skype from animating (in gnome-panel) when offline
  skype without any dbus  access?
  
  /etc/network/if-post-down.d/stop-skype
  sleep 10s
  killall -STOP skype
  
  /etc/network/if-up.d/resume-skype
  killall -CONT skype
  
• keep cpu at minimum
  /etc/pm/sleep.d/20-cpuspeed
  case "$1" in
          resume | thaw)
  sudo cpufreq-set --governor powersave
  foreach dir (/sys/devices/system/cpu/cpu*/cpufreq/) {
     echo powersave | sudo tee $dir/scaling_governor
     echo 1199000 | sudo tee $dir/scaling_min_freq
  ...
  #sudo hdparm -Y /dev/sdb
  
  
  

Shell skeletons

Shell skeletons --- a tool to start using a sequence of commands

When I started to build debian packages from Git, I adopted git-buildpackage.
The steps I used were (at least) 7:

• git-dch  --release "--debian-tag=michal/%(version)s"
• git add debian/changelog; 
• git commit -m release
• git-buildpackage --git-tag "--git-debian-tag=michal/%(version)s" 
• debi --debs-dir ../build-area/
• git-buildpackage -S
• debrelease -S  --debs-dir=../build-area --dput

I had this recipe in a file/editor, and pasted line by line into shell, possibly adapting the text, and then invoked.
In case of error I could reinvoke the command, with some modification.

Then I learned that with Zsh, I can programmatically use that feature which implements C-q (push-line):  there is a stack which I can pre-populate, and then
ZLE will  prefill the command line by popping the strings from the stack.

So I came up with this function:

zload-file () {
        file=$1
        setopt nomonitor
        coproc tac $file &|
        while read line
        do
                builtin print -z $line
        done <&p
        wait
        setopt monitor
}

Sure, I have to put the lines in reverser order -- the last one to be pushed as first, so that it ends at the bottom.

PS: After a while I learned/realized all the arguments of those commands, and made scripts (release & snapshot) which hide all the details, and expose different set of options-- those which I care about.

Git-hierarchy --- how to use

Documentation on git-hierarchy.

Definitions:

Note: when I say branch, I mean the named head.

A "feature branch", or a segment, is a triple:
1/ branch
2/ start commit reference. (points to a real commit - sha1-hash)
3/ base symbolic reference -- name of branch to re-base it on.

A sum is a branch name and a list of summands -- symbolic references
of branches, which should be (re-)merged to form the "unique commit" of the branch.

Sums are handy for:
- the final release commit
- as the "base" reference for segments.

poset: the partial ordering of (relevant) heads, induced by:
 segment-head > the head referenced by the base symref.
 sum-head > each of the heads referenced by the list of summands.

Operations:

git-segment  list, describe, create segments, split
git-sum    list, describe, create, modify  sums

git-rebase-poset the main tool -- rebase/remerge all the sums & segments.
so that for each segment  start is (again) equal to base, and sum-heads commits are joins of the summands.

git-rename  .. when renaming branches, rename the whole segment/sum, or
               update the other symbolic references to reference the changed  name.

git-delete  .. check if possible to delete the sum/segment, or if anything is
               referencing it -> abort.

Implementation:

start ... could have used tags. not now.
bases ... symbolic references; ex.  ref/base/antiflicker points at "ref: refs/heads/master".

summands ... symbolic refs. ex.  ref/sum/all/1  points at "ref: refs/heads/antiflicker",        ref/sum/all/2 points at "ref: refs/heads/auto-raise ...

Transferring to other repos

For now it's only a tool for individual use. There are some limitations in Git, which I had to work around:

• "git push" resolves symbolic refs before sending them.
• "git fetch" from GitHub does not fetch refs other than tags & branches.

So, if I want to at least transfer the structure, I need to patch git, or use this trick:

I can for example make a tag whose message -- as string -- is a table - dump of the symrefs:
sym-ref-name      ref: .....

git tag "hierarchy-refs" -m "$(git-dump-refs)"
and on fetching:
git cat-file tag hierarchy-refs |tail -n +6 |  git-recover-symbolic-refs

System to keep a hierarchy of modifications for public software.

System to keep a hierarchy of modifications for public software.

I have developed a few extensions to free/open software, over past years.

Doing so in spare time, my priority was to get the features done,
at the cost of code quality, sharing(?).

During years, naturally, a need arose to re-apply those big patches to
evolving upstream sources.

So, inspired by Debian, I started to experiment with Quilt, and
represented my modifications as progressions of patches.



But there were certain projects, where my changes were so big,
that I was not able to extract such a linear sequence without
additional tools.

With the help of Git and especially Magit, I started to
classify separate diff hunks, then group those classified as related
and regroup etc.

  (I did this for my changes to Sawfish WM).

The whole set of changes grew to be  layers of changes, some dependent
on previous ones;  not a previous one, but more of them.


So I wanted to understand this partial ordering, and somehow represent it in Git.

The benefit for this would be easier future rebasing upon new upstream,
since rebasing smaller parts requires  less knowledge (decisions) at a time. And
some of my features can be also implemented upstream -- so I can just drop that
part of my changes, and  adapt/rework the rest.


Single "features" are thus represented as a linear sequence of commits,
and the dependency between them is represented by "basing" one  "feature"
on  a merge (commit) of  prerequisite features.


So, in my current version, I have merges - "sums", which are just lists
of features - "segments". And "segments" are "branches"  with
a Start commit (a hash id), and a symbolic "base", which is a "sum".
That base-sum can also be a trivial sum -- a simple  segment.

Rebasing such a hierarchy is a matter of walking in the topological order of
the dependency (between features -- segments) and sums,
rebasing them --onto the updated "bases"  or  redoing merges.



Code is here