Sometimes I forget to commit a modification, and running "propellor --spin" automatically commits this stuff. It would be better if "propellor --spin" failed (or, even better, warned the user) that there are uncommited changes, and "propellor --spin" would just always add an empty commit.
Letting --spin commit is part of my workflow. It's great when you're just changing config.hs to quickly blast out the changes.
Granted, it is not so nice when doing Property development, as changes get fragmented across the spins used to test them. I'd be happy to find some way to improve that. Perhaps a way could be found to get this structure of git commits:
Where the second manual commit has an identical tree committed as does the spin just underneath it, and so the following merge doesn't change any files, just grafts the two branches back together.
I guess that could be handled by haing a checkpoint command, that squashes all the previous spins since the last checkpoint together into one commit, lets the user edit the commit message of that, and the juggles the branches into place and creates the merge commit -- which then becomes the new last checkpoint.
I'll take patches for such a thing, or more simply a way to configure --spin's auto-committing behavior. However, I don't want to change the default behavior to not commit.
Here's a almost-script to do it, which worked when it did it by hand: