https://allspice.io/post/git-for-hardware-commit-best-practi...
Ask HN: How do you document your hardware projects?
11–20 of 42 posts
Re: Ask HN: How do you document your hardware projects?
#12Self hosted Gitea + Markdown + Mermaid diagrams
Re: Ask HN: How do you document your hardware projects?
#13Re: Ask HN: How do you document your hardware projects?
#14http://emsoftware.com/products/docsflow/ for GSuite to Indesign.
Re: Ask HN: How do you document your hardware projects?
#15Mechanical Engineer here - this is the million dollar question. We currently use antiquated systems, or bad software based on antiquated systems. My approach - don’t rely on software. It’s a mentality, not a software. Your CAD should be organized in a future proof structure. Your analysis should reference the hardware by diagram. You should be able to easily find the analysis with nothing more than a hunch. Your draw…
- Designing a UI for resolving merge conflicts is non-trivial and a lot of the visual cues git diff viewers use to highlight conflicts (colors, marker text, etc.) don't translate well into a CAD viewer
- The Autodesks and Bentleys of the world work in proprietary binary files so any solution would only work for one vendor, and sometimes only one flavor of one vendor
Re: Ask HN: How do you document your hardware projects?
#16But nothing prevents such a system from working with arbitrary files, as long as there is a tool to create a "patch" or a "diff" (that is, a description of a change) and a tool that can apply such "diff". Git does have a mechanism to plug in both of these tools, depending on the file type.
I have a very vague idea of what CAD files are internally, but I suppose they are some kind of a database, and they are not colossal (unlike e.g. video files or such). They certainly could use this mechanism to allow tools like git (or hg, or maybe even perforce) be used in workflows involving CAD files, with human-understandable and reviewable changes.
I wonder if someone has ever tried that. I can't be the first person to have this obvious idea.
Re: Ask HN: How do you document your hardware projects?
#17Just thinking aloud. Change-tracking software like git works with "patches", that is, changes applied to a source file to produce the changed file. They are hardwired to work with text files like source code, with short lines, and with line-oriented changes. But nothing prevents such a system from working with arbitrary files, as long as there is a tool to create a "patch" or a "diff" (that is, a description of a cha…
Re: Ask HN: How do you document your hardware projects?
#18Re: Ask HN: How do you document your hardware projects?
#19Mechanical Engineer here - this is the million dollar question. We currently use antiquated systems, or bad software based on antiquated systems. My approach - don’t rely on software. It’s a mentality, not a software. Your CAD should be organized in a future proof structure. Your analysis should reference the hardware by diagram. You should be able to easily find the analysis with nothing more than a hunch. Your draw…
Re: Ask HN: How do you document your hardware projects?
#20Just thinking aloud. Change-tracking software like git works with "patches", that is, changes applied to a source file to produce the changed file. They are hardwired to work with text files like source code, with short lines, and with line-oriented changes. But nothing prevents such a system from working with arbitrary files, as long as there is a tool to create a "patch" or a "diff" (that is, a description of a cha…
I think version control like this would work great with programmatic CAD like OpenSCAD
I'm more interested in tracking and versioning edits to KiCAD schematics, for instance.