One commit = one change
blair at orcaware.com
Mon Mar 5 17:32:22 PST 2007
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.
More information about the macports-dev