# PRs and granularity

**URL:** <https://meta.discourse.org/t/prs-and-granularity/49162>\
**Category:** Development\
**Created:** [August 24, 2016, 7:02pm UTC](https://meta.discourse.org/t/prs-and-granularity/49162 "2016-08-24T19:02:31Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![mpalmer](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mpalmer/32/45740_2.png) [@mpalmer](https://meta.discourse.org/u/mpalmer)\
**Post date:** [August 24, 2016, 10:39pm UTC](https://meta.discourse.org/t/prs-and-granularity/49162/4 "2016-08-24T22:39:49Z")

</div>

On the “git magic” side of things, if you have the same sort of OCD I have and wanted to split out the changes into separate commits, as long as each logical change was in a separate “hunk” (sections of code delimited by lines starting with `@@`), you can do:

1. Get a second branch with your code on it (so you’ve still got the original commits easily available if you make a mess):

2. “Uncommit” all your changes in all your commits:

3. Now if you run `git status`, you should see that `mbox.rb` is shown as having “Changes not staged for commit”. Excellent…

4. Run `git add -p`. This will present you with a single “hunk”, and ask if you wish to stage it for commit. When you say `y` or `n`, it’ll go on to ask you about the next hunk, and the next, and so on. The plan here is to say `y` to all hunks that are logically associated with each other, and say `n` to all other hunks. If you make a mistake, you can `q` out of the whole process, run `git reset HEAD path/to/mbox.rb` to “unstage” all the hunks you said `y` to, and re-run `git add -p`.

5. Once you’ve said `y` to a bunch o’ hunks, you can review the set of hunks you’re about to commit with `git diff --cached`. If they look good, then make a commit with `git commit` (if you’re used to putting a `-a` on your `git commit`, now is the time to unlearn that habit).

6. Repeat the `git add -p; git diff --cached; git commit` dance several times until you’ve committed all the hunks in separate, well-described commits.

You can also use `git rebase -i` to reorder and squash commits into fewer, larger commits, but that’s a fairly ninja process with a reasonably high probability of getting yourself very, very confused. I only reach for the `git rebase -i` when I’m in dire straits, myself.

---

_[View the full topic](https://meta.discourse.org/t/prs-and-granularity/49162)._