A better criterion for determining when to display the message would be to count the non-empty lines of the diff, and only show it if it passes a threshold.
Or: only if the added/removed lines ratio is > 1, or something like that.
A better criterion for determining when to display the message would be to count the non-empty lines of the diff, and only show it if it passes a threshold.
Or: only if the added/removed lines ratio is > 1, or something like that.
I think commiting should be done for a more meaningful unit of work than a single edit, something logically 'complete' akin to a transaction.
> I think commiting should be done for a more meaningful unit of work than a single edit, something logically 'complete' akin to a transaction.
What do you think would be a good set of criteria for what should count as a meaningful unit of work?
I'd consider a meaningful unit of work to be a bug fixed, or feature implemented, at least to the extent that you have a runnable version of the code again (even if you intend to do further work to implement it better e.g. replacing hard-coding). I'd consider changes short of this as not worth commiting, as this would not be a good starting point for further work (I know it's cheap to branch with Git etc., but it just feels untidy to leave something so part-done).