kicad-developers team mailing list archive

[Chris Morgan <chmorgan@xxxxxxxxx>]

On Fri, Jan 3, 2014 at 9:02 AM, Brian Sidebotham
<brian.sidebotham@xxxxxxxxx> wrote:
> Sorry, I've been off-list for a while whilst building my house over Christmas.
>
> bzr works fine and is what Launchpad hosted projects work with most
> easily. I don't see anyone wanting to change, especially as there's no
> real reason to change; Besides, bzr usage is included in the build
> system now too, so the commitment to bzr from KiCad appears clear.
>
> Tim/Chris, it's best to tell us what you're struggling with. All you
> have to actually do to contribute is:
>
> bzr branch lp:kicad
> *make changes*
> bzr diff > new_feature.patch
>
> and email the patch to the developers list for review. Make sure you
> read the coding policies too. There's not much to bzr workflow, it's
> very typical distributed workflow.
>
> Best Regards,
>
> Brian.

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)?

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?

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.

Chris