kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

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

Attachment: signature.asc
Description: OpenPGP digital signature