KiCad, version control and merging

Yep, I had to keep reverting section that do not really change in the text files crazily to the point I wish I can have time to change the kicad code of loading and save file so that it respect the original order of items, and only apply the sort for new added items some how.

It isn’t my experience with kicad sch files, could you be clearer on which parts of the files change without notice?

I’m talking about the symbol .lib files. I would avoid diff text in schematic file, it just too hard to make sense of it.

I really like your blog post. But there is one thing missing that drives me nuts. Maybe you have a solution for that: why does kicad save the currently visible layers of a PCb in the kicad_pcb file? In my opinion this should be stored in a user file as it carries no useful information for the project.

In my case I work with several projects. Every time I open a project I like to meet the same selected layers I left when I closed it.

And I usually have different layer selections in different projects, so this behaviour is desiderable for me.

It’s not about whether it’s saved in the project, but about in which file it’s saved. There could as well be a .pro.user or kicad_pcb.user file which would have the user specific information. That could be ignored by git because you hardly want to put layer selection into versioning or share it with others.

2 Likes

If i remember correctly then there was talk about that on the mailing list. But it happened to late for getting it into v5.
So i guess it will come with version 6.

Exactly :slight_smile:

Awesome :partying_face:

That’s surely another opportunity to use git’s clean/smudge feature. I don’t know kicad_pcb files, so can you provide a sample of the offending diff and a safe value for the changing lines?

Using clean/smudge is not about changing this behavior, it’s a way to make git ignore it when committing and diffing.

Sure. For example, you can see that I changed the visibility of B.Paste from hidden to visible and Dwgs.User from visible to hidden. It would be enough for me if all layers are always shown (ignoring the hide keyword entirely).

    diff --git a/pcb/Nixie_Clock.kicad_pcb b/pcb/Nixie_Clock.kicad_pcb
    index 75d2999..1d0d100 100644
    --- a/pcb/Nixie_Clock.kicad_pcb
    +++ b/pcb/Nixie_Clock.kicad_pcb
    @@ -13,17 +13,17 @@
       (layers
         (0 F.Cu signal)
         (31 B.Cu signal)
    -    (34 B.Paste user hide)
    +    (34 B.Paste user)
         (35 F.Paste user)
    -    (36 B.SilkS user hide)
    +    (36 B.SilkS user)
         (37 F.SilkS user)
    -    (38 B.Mask user hide)
    +    (38 B.Mask user)
         (39 F.Mask user)
    -    (40 Dwgs.User user)
    -    (41 Cmts.User user)
    +    (40 Dwgs.User user hide)
    +    (41 Cmts.User user hide)
         (42 Eco1.User user hide)
         (43 Eco2.User user hide)
    -    (44 Edge.Cuts user)
    +    (44 Edge.Cuts user hide)
         (45 Margin user hide)
         (46 B.CrtYd user hide)
         (47 F.CrtYd user)

Ok, so let’s define a new filter attribute for this kind of files in the current project.

echo '*.kicad_pcb filter=kicad_pcb' >> .gitattributes

If you wish to disable the behavior later, remove this line from the .gitattributes of your project.

Now, the content filter, assuming that the lines in the diff don’t need more context to be matched:

$ git config --global filter.kicad_pcb.clean "sed -E 's/^( +\([0-9]+ .+ (user|signal)) hide/\1/'"
$ git config --global filter.kicad_pcb.smudge cat

WARNING tested on sample project. Take with caution, it might break your commits. Please test on a dedicated branch

2 Likes