One commit = one change

[Blair Zajac]

Ryan Schmidt wrote:
> Dear MacPorts committers,
> 
> I've seen a lot of commits to portfiles that do more than one thing. For 
> example, a commit that updates the port to a new version, adds a new 
> variant, and changes the indentation of the entire file. This makes it 
> incredibly difficult to see what actually changed, and I would very much 
> appreciate it if we could get into the habit of committing each logical 
> change separately.
> 
> For example, if you want to change the indentation of the file, do only 
> that, then commit it, with a log message that says you're changing the 
> whitespace. If you want to upgrade to a new version, do just that, and 
> commit it with an appropriate log message. If you want to add a variant, 
> do that, and commit it. This way it is much easier to look through the 
> Subversion log and especially the diffs and see what was changed and 
> why. If you do it all at once in a single commit, especially whitespace 
> changes which like to affect every line, it's very difficult to see what 
> was really changed, and this hinders people like me who are trying to 
> learn more about MacPorts, portfiles, and compiling software in general.
> 
> Hand in hand with the idea of one change per commit is the idea of 
> accurate log messages. Your Subversion log message should say exactly 
> what you changed. Don't omit anything!

I totally agree on separate commits for logical changes in general, 
however, I'm of the mind that only whitespace change commits should be 
separate.  I don't see the need to have separate commits for a new 
version and a new variant, after all, the developer may have tested them 
together, and testing them separately may be more work.

Now if there's a complicated update and there's also other things that 
change, then yes, split them up.

Regards,
Blair