Question

I have a CMS that uses git to track changes to user content – I have them rolled up into a single commit every night. As you can imagine, one commit every day has made for an interesting commit log.

I’d like to tidy up a bit, and was thinking I could do so by rebasing the commits (about 100 or so) into a single commit. Is this an appropriate strategy for these automated commits? Will I run into collisions if the same file is referenced in two or more commits? Something seems to be too easy about just rebasing the 100 into 1.

E: These are content changes, not codebase changes, so they’re not really important. It would be nice to roll the changes up every once in a while to clean up the history.

Answer 1

By running rebase -i <upstream> and marking the 100 commits as “squash” commits in the prompt that Git provides, you should have no problems. Git will apply each patch, one after another, and you’ll end up with a single commit reflecting the state of the repository at the final commit. Choosing “fixup” will do the same thing, but will drop the intermediate commit messages (which sounds more like what you’re looking for).

And if you run into some unforeseen issue while rebasing, a simple git rebase --abort will restore you to your original repository and version history.

Git is very space efficient, however, so if you don’t want to lose the history, you could try running git gc. This runs the Git “housekeeping” tasks, such as compressing the commits into “Packfiles.” If the user content doesn’t change significantly day-to-day then Git should be able to compress your history very tightly. git gc --aggressive will work even harder to compact your commits.