The Amp Hour Electronics Podcast

A weekly show about the trends in the electronic industry.

You are here: Home / Radio Show / #530 – Living Through Chipageddon

#530 – Living Through Chipageddon

Play

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS

Comments

  1. About 24 minutes in, Chris made a comment about not being able to have multiple versions side-by-side. It’s unclear from context whether he means doing so isn’t what he wants to do or that he things Git can’t do that.

    On the chance that he meant the latter, Git *can* do that using the worktree feature:

    cd ~/path/to/main/checkout
    git worktree add ../rev-b rev-b
    git worktree add ../rev-a rev-a

    Now you can switch versions from the current to rev-b with “cd ../rev-b”.

    Git’s been able to do this since version 2.5, but people keep learning this switch-in-place work style that tosses your current version and replaces it with the new version every time you switch. That’s fine when you’re changing versions in a one-way sort of manner, but when you need multiple parallel versions available, switching with cd is far saner.

    Under this scheme, I’d normally call the default checkout directory “main” or “master”, named after whatever the default branch is in the repo. So, to get back from rev-b to the current version, it’s “cd ../main”.

    While I have your attention, can I recommend that you look into Fossil, a version control system better suited to small teams working cohesively on a project, where Git’s made for massive Internet-wide sprawling teams of disconnected users?

    https://www.fossil-scm.org/

    It’s made to be stood up on your own server rather than use [free] public hosting, but there’s a mirror-to-GitHub feature so you can have an output on GH while you continue to work on your local clone(s) of the repo.

    • Immediately after this, Chris invited reasoned arguments for why you don’t check generated files into a source repo if the file they’re generated *from* is also checked in.

      There are a bunch of good reasons:

      1. It bloats the repo with files that are usually of a type that don’t delta-compress well. Scroll down about halfway into this paper to see a graph of what happens to the repo size when you put such files into a source code repo:

      https://www.fossil-scm.org/home/doc/trunk/www/image-format-vs-repo-size.md

      That study was done with Fossil, but it’d happen just as well with Git. Compressed PDF schematics would show this problem, though I don’t think Gerber output would, since Gerber’s plain text, last I checked.

      2. If you can’t reliably re-generate the output files from the input files, it means you’ve got a non-repeatable process. That should get your inner engineer all itchy. EAGLE has a CAM feature that produces a small file describing the Gerber and Excellon generation steps, and you check *that* into the repo. Anyone with the EAGLE board file and the CAM file can then reliably produce identical Gerber outputs.

      According to what I’ve been told about KiCad, it doesn’t have such a feature, requiring that you manually type numbers into a GUI on Gerber export that don’t get saved in the board file? If true, then I can see why you’d want to save the generated Gerbers in the repo, since they’re hard to recreate. *That’s* the actual problem here, not #1 above, repo size bloat. Make your process repeatable!

      Ideally, “building” new outputs should be a few keystrokes / GUI button clicks at most.

      3. Generated files are often temporaries of some sort. Deleting them and re-opening the input file will re-generate them, so they shouldn’t be checked into the repo.

      • Good points all around. When I think about it more, it’s really just the schematic that I feel needs to have a copy saved for reference. I think about it almost like documentation output, rather than manufacturing. I regularly need to compare one to another. Perhaps I’ll generate and embed it into the README.md to get people feeling ok about the files being there 😀

        > That’s fine when you’re changing versions in a one-way sort of manner, but when you need multiple parallel versions available, switching with cd is far saner.

        Agree! Very interesting point about the “worktree” feature. I will have to play around with that. This feels like one of those “not knowing what to google for” type of problems, I can’t imagine how I would have found out about this feature aside from the goodwill from folks such as yourself. Thanks for the pointer!

      • After listening to this episode this morning, I thought I’d post about why not include outputs in the git repository, then found that Warren had written pretty much all I had intended to say. So, “ditto!”

        I use Eagle (what can I say, I recently renewed my Eagle/F360 sub…) with git. Works nicely because the schematic and board files are text and I can see what’s changed in each commit (if small changes). I exclude the outputs directory from this. But I include my .cam file, and tag releases, and so can checkout a release and click one icon and reliably regenerate all CAM outputs – so why include them in the repository?

        But I also keep folders on my PC, one per release, with a copy of everything pertaining to that release – PDF schematics, gerbers, BOM, firmware if relevant, test results, assembly quotes, whatever. Just don’t see the need to keep any of that in git.

  2. Hi! Thought I’d post this here as it’s related to the flatbed scanner discussion:
    Harvard Science Book Talk – Felice Frankel, “Picturing Science and Engineering”
    https://youtu.be/NSM6e0wtrI0?t=1764 starts from the scanner segment

    Amongst other things she’s shot several covers to this niche journal called nature so the whole lecture is pretty good 😀

    Have a great day!