I’m not sure if this is the best place to ask this, but I am wondering how to make multiple separate contributions to the KiCad schematic and footprint libraries. I have some fairly large symbols and footprints that are currently pending, but I would also like to contribute smaller (unrelated) changes, additions, and fixes in separate pull requests. Am I able to do this without creating additional branches?
You need one branchper pull request.
1 Like
FYI: branching is a big problem for companies to be productive - including Google. Let along excessive use of pull request is another one. Pull request is not equiv. or replaceable with code review.
Branching is how git is meant to be used whatch a talk by linus if you do not take my word for it. Meaning if branches do not fit your workflow then git is not right for you.
If you can step out of the Linus food, you will see what I mean. Look at how industry doing, they doing the Trunk base model, not branch model. Research, you will find why. But, the history of 15 years + already proof by SVN. If still not convincing, you can find modern book as about DevOp.
It is not really trunk vs branches but centralized vs decentralized. You can use git with a single branch but i see no reason to do so. (The power of git is that you can branch and merge easily.)
What is used depends on the company. The company i work at right now uses both models depending on the needs. They use svn (and something similar) for things that can not be merged but use git for everything else.
The only difference they make compared to github is that their server is setup to disallow force pushes by default. (removes some points of error but also some power of git as one can no longer rebase for example.)
I have heard similar stories from nearly everyone i studied with.
git for sourcecode, svn for pcb design seems to be the way it is in the industry. And also git for digital chip design, something even stricter than svn for analog chip design.
And then there are the mechanical engineers who do not use version control systems at all but rely on having one file per version on a central server. (Luckily the new more expensive tools include version management behind the scenes. Meaning version control even enters these fields. In this case it is a centralized workflow because such data is not mergeable.)
There is also a third model used. A mixture of git and svn. In such cases git is used for the day to day stuff or for working with the group you are in but one large svn repository (or similar) is used for the main data collection of multiple groups. (One reason for this is that svn allows partial checkouts.)
Part of the reason why git is not used more is that it was only developed in 2005. This is quite recent for companies to make such a change. (I heard stories of companies still being on cvs and thinking for years what to switch to and how to do it without investing too much time/money.)
Luckily there are tools out there that make it easier to switch over.
I think nhtakhai’s comment was more about software development uses of git.
I can attest that most major companies in the software industry indeed use git or any other system (I’ve seen mercurial at one place and even a proprietary one at another company that-shall-not-be-named because they reinvent everything) without using branches in mainline. Their model is that you are free to have any local branches you want, as many of them as you like, in fact it is encouraged to parallelize feature work and unblock yourself while your code is in review etc. But everything that gets pushed to main repo gets rebased onto trunk, automatically tested with miriad of tests, linters, nude virgins and commit hooks and then it makes it into the repo. If you are lucky and all checks passed and the virgins are not cross with you for any reason.
Even in oss git community there are two schools of thought:
- Merge commits are the devil and are to be avoided at all costs!
- Rebases are the devil since they don’t preserve mah’ history!
I personally am in the first camp which aligns with what all large companies do. Because who gives a shit about local history of each dev, the main line is the only thing that matters and it’s so much easier to track anything down when it’s just a simple timeline with no branching caused by merges.
There may be reasons why linux kernel and as a result git is heavily leaning towards merging and branching. But it definitely does not work well in software giants.
As far as KiCad’s use of git I would imagine merge conflicts are a nightmare to resolve since it’s not source code. So it’s very reasonable to request the contributor to resolve all conflicts first and easiest way to do this is to rebase and manually redo the changes in the right editor that understands the data be it eeschema or pcbnew.
1 Like
What you describe would be my understanding of how branches where intended to be used by linus himself. The only difference being that every group can have a fork of the main git repo where they push their local branches to. (This is because people working on the same feature will need access to the same branches.)
This model can even be adjusted to have multiple layers.
What you describe is also what we use for the libraries by using pull requests that are tied to your personal fork and its branches. (I have no idea why github calls this pull request. I find the gitlab name mergerequest much more fitting.)
A good description of the different workflows is here: https://www.atlassian.com/git/tutorials/comparing-workflows (I personally like the feature branch workflow combined with atomic commits and squashed merging into the main branch.)
git bisect is best with trunk model, terrible to work with merging branches.
No only that, pull request is a totally wrong way of promoting fast development. We let the developers to fast-forward merge only as much as they like without any approval in pull-request. We use CI for help prevent some bad merge from bad code, but free to merge at any time. This show my team work more productive than using pull-request as a must. The longer the pull-request stay, the more developer reinvent or break code that going the be merge, or the branch become more work to do than re-code again from head.
It remind me of the need of git LFS.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.