On 10 Jul 2019, at 08:37, Tomasz Moń wrote:
> My general experience with splitting big changes into small commits
> *after* they are done is rather bad. That is, the artificially
> splitted changes I have seen were failing to work (sometimes even fail
> to compile individually). As I find such artificial splitting to be
> harder than the actual development, I always tend to commit as small
> pieces of code I see fit for a single commit.
I agree with you. But it's a reverse engineered protocol, and I only got
the complete picture of how it works by implementing all new functions,
and then step by step renaming the parameter.
My question was also related to the ones who do the code review. Also
many small commits will result in many compiler test-runs. I don't know
how many ressources they take.
I've started to split my big commit into smaller ones, I think this will
be possible without having a non-working version in between.
--
Thomas
