kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 3 January 2014 14:09, Chris Morgan <chmorgan@xxxxxxxxx> wrote:
> I'm not actively making changes but in case it helps someone else,
> here is what was confusing me. This is something I do a few times a
> day with git in order to keep history clean and integrate patch review
> feedback.
>
> How to get upstream changes while making local changes (or if I had a
> few local commits)?

Just merge the current tip:
bzr merge lp:kicad

> The other thing I couldn't figure out was how to modify local changes,
> and how to modify changes that were one or more changes behind my
> latest change. So if I wanted to build up a patch series how do I
> clean that up based on feedback or things I've learned along the way?
>
> ...
> - commit X (upstream HEAD)
> - commit 1 (local change)
> - commit 2 (local change / local HEAD)
>
> How to modify commit 1?

Changing your workflow here will probably help if you want to work on
different features at the same time, rather than trying to shoehorn
that into one feature per commit, which I guess is what you're trying
to achieve.

Just branch locally as it's cheap:

bzr branch ./kicad ./kicad-newfeature-1
bzr branch ./kicad ./kicad-newfeature-2

etc. Then commit locally as many times as you like in each feature. If
you're doing parallel development and need both changes
simultaneously, you could branch again and merge both features in,
etc.

Don't use bzr like git or svn or rcs or anything else, it's bzr and
git's git! They do not have direct translation to one another.

> It might help to document how to map these operations from git to bzr
> on the kicad page to help get people familiar with git up-to-speed.

Contributing to KiCad is extremely easy given you only have to branch,
make changes and then create a patch and email it to the list. Please
feel free to use this easy method to contribute your first changes.

Best Regards,

Brian.