Hi James, On 12.05.20 18:36, James Jackson wrote:
> However, I've noted in a few bug reports and new feature > requests that there are likely to be significant changes to eeschema > moving towards v6 (last reference I saw was in relation to vector and > group busses). So, is it wise to start looking at a significant feature > now (if the big changes have happened already), or wait until those > changes are made, or is this not actually an issue? Just trying to avoid > wasting effort and then have to re-duplicate it later! Rebasing branches usually works for me, even with slightly conflicting changes -- perhaps the most important thing you can do in a large refactoring is to make each commit as small as possible while still being thematically consistent, and to make sure that every commit on its own compiles. So a refactoring change usually consists of 1. add new internal interface (just exists, isn't used yet) 2. move dialog 1 over to the new interface 3. move dialog 2 over to the new interface ... n. remove the now-unused old interface This allows me to just throw CPU power at rebasing. The two most important commands are $ git rebase -x 'make -C Build -j`nproc`' origin to verify that indeed every commit still compiles after rebasing, and $ for i in $(git rev-list --reverse $(git merge-base HEAD origin)..origin); do git rebase $i || break; done to rebase your branch one commit at a time to minimize conflicts. You can even combine them to $ for i in $(git rev-list --reverse $(git merge-base HEAD origin)..origin); do git rebase -x 'make -C Build -j`nproc`' $i || break; done but this will take an absurd amount of time, usually directly rebasing is sufficient. Simon
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
