2ca376f6d6
* Add target 'build-for-compare' to `build_keyboard.mk` The `build-for-compare` target provides an easy way to check the md5 checksum of the generated binary. You can easily see if there is any change in the generated binaries between the two versions, as in the example below. ``` $ git checkout 0.11.0 M build_keyboard.mk M tmk_core/rules.mk Note: checking out '0.11.0'. HEAD is now atc66df16642020 November 28 Breaking Changes Update (#11053) $ make helix:all:build-for-compare | grep ^MD5 MD5 (.build/helix_rev2_default.hex) = 5c3606562c944bb4d18832e601b45d4a MD5 (.build/helix_rev2_edvorakjp.hex) = 9e43d13d389d518ba7e99cd7337e28d6 MD5 (.build/helix_rev2_five_rows.hex) = 8bcb61c2fd5d237c2997f2fa007d4934 MD5 (.build/helix_rev2_five_rows_jis.hex) = b97cd818d52f73ca2d4e78c86d90a791 MD5 (.build/helix_rev2_froggy.hex) = c492172364188f4e2918b10bf0f3a0a6 MD5 (.build/helix_rev2_froggy_106.hex) = b0861fd735a8f81881a8c02730641a2b MD5 (.build/helix_rev2_led_test.hex) = 5c97d982a5da5cfb3dacb28a8934b81d MD5 (.build/helix_rev2_xulkal.hex) = 01f603dc46bcf9094d7e106831d8f5b1 MD5 (.build/helix_rev2_yshrsmz.hex) = 5a008bca2d0c5790a151c02834c529ba $ git checkout 0.11.1 M build_keyboard.mk M tmk_core/rules.mk Previous HEAD position wasc66df16642020 November 28 Breaking Changes Update (#11053) HEAD is now atcc08e3082nix-shell: add milc dependency (#11086) $ make helix:all:build-for-compare | grep ^MD5 MD5 (.build/helix_rev2_default.hex) = 5c3606562c944bb4d18832e601b45d4a MD5 (.build/helix_rev2_edvorakjp.hex) = 9e43d13d389d518ba7e99cd7337e28d6 MD5 (.build/helix_rev2_five_rows.hex) = 8bcb61c2fd5d237c2997f2fa007d4934 MD5 (.build/helix_rev2_five_rows_jis.hex) = b97cd818d52f73ca2d4e78c86d90a791 MD5 (.build/helix_rev2_froggy.hex) = c492172364188f4e2918b10bf0f3a0a6 MD5 (.build/helix_rev2_froggy_106.hex) = b0861fd735a8f81881a8c02730641a2b MD5 (.build/helix_rev2_led_test.hex) = 5c97d982a5da5cfb3dacb28a8934b81d MD5 (.build/helix_rev2_xulkal.hex) = d848383adfd7463b138c6da179cf1436 MD5 (.build/helix_rev2_yshrsmz.hex) = 5a008bca2d0c5790a151c02834c529ba ``` * make builds reproducable by default * update build_keyboard.mk: remove 'build-for-compare' target * GNU make (3.81) on macOS 10.14(Mojave) does not have the 'undefine' directive. * Adopted fauxpark's suggestion. * Update tmk_core/rules.mk Co-authored-by: Ryan <fauxpark@gmail.com> * update tmk_core/rules.mk * fix tmk_core/rules.mk Co-authored-by: Zach White <skullydazed@gmail.com> Co-authored-by: Ryan <fauxpark@gmail.com>
ZSA's fork of QMK Firmware
This purpose of this fork is maintain a clean repo that only contains the keyboard code that we need, and as little else as possible. This is to keep it lightweight, since we only need a couple of keyboards. This is the repo that the EZ Configurator will pull from.
Supported Keyboards
Maintainers
QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, Hasu. The ZSA branch is maintained by Drashna, ZSA's official QMK Liaison, and by Florian Didron, ZSA's lead developer, with input from Erez Zukerman (ZSA CEO).
Update Process
- Check out branch from ZSA's master branch:
git remote add zsa https://github.com/zsa/qmk_firmware.gitgit fetch --allgit checkout -B branchname zsa/mastergit push -u zsa branchname
- Check for core changes:
- https://github.com/qmk/qmk_firmware/commits/master/quantum
- https://github.com/qmk/qmk_firmware/commits/master/tmk_core
- https://github.com/qmk/qmk_firmware/commits/master/util
- https://github.com/qmk/qmk_firmware/commits/master/drivers
- https://github.com/qmk/qmk_firmware/commits/master/lib
- These folders are the important ones for maintaining the repo and keeping it properly up to date. Most, but not all, changes on this list should be pulled into our repo.
git cherry-pickthe commits we wantgit rm docs/* -rto remove the document updates when cherry picking. Repeat for any keyboard/keymap/etc that have changes that we aren't interested in
- Commit update
- Include commit info in
[changelog.md](http://changelog.md)
- Include commit info in
- Open Pull request, and include information about the commit
Strategy
To keep PRs small and easier to test, they should ideally be 1:1 with commits from QMK Firmware master. They should only group commits if/when it makes sense. Such as multiple commits for a specific feature (split RGB support, for instance)
Merging
Pull Requests should be merged/rebased, not squashed, so we can maintain a commit history that is close to QMK Firmware's, for ease of reference.