3 ms·
I think it's more natural. Commit A: introduce the bug Commit B: change architecture Commit C: add a feature Commit D: fix A using code present
by cogman10 1y ago
I think it's more natural.
Commit A: introduce the bug
Commit B: change architecture
Commit C: add a feature
Commit D: fix A using code present in B and C.
The issue ends up being that D needs to be reimplemented to fix A because B and C don't exist on the tip.
Since linux has closed windows and long term kernels it means the fix to the same bug could need to be done in multiple ways.
Multiple changes per PR is bad, but I assume it's still one change per commit.
- fooqux 1y agoYeah, but then you run into scenarios where A+D is tested and ready, but B and/or C are not. Git does give you tools to separate them, but most people don't like doing that for various reasons. IMHO, it may be more natural, but only during development. Trying to do a git bisect on git histories like the above is a huge pain. Trying to split things up when A is ready but B/C are not is a huge pain.