7 ms·

Improve your Git commits using patch mode

30 points by codenapper 14y ago

languagehacker 14y ago
I'd suggest adding hunks instead of committing them so you can review your staging area at the end. It's the same flag; just use 'git add -p' instead of 'git commit -p'.
- ujeezy 14y ago
  And if you'd like to diff what's in the staging area, you can use this command: git diff --cached
- codenapper 14y ago
  Thanks, that's really helpful! I just updated the post.
deleted 14y ago
[deleted]
jakub_g 14y ago
FYI, in case you added reaaally a lot of stuff, and want to split it into smaller commits, it might be much more handy to do partial commits using Git GUI (select lines in the file & right click to have a popup menu with appropriate option). Also, don't do it the next time. Side hint: for things like fixing typos, I found that creating a new branch, say 'typos', is quite handy solution to not do these kind of things in the commits that are meant to add new things / fix bugs. Just checkout typos, fix, commit, checkout master / feature branch.
- emillon 14y ago
  For typos, `commit --fixup` is an invaluable tool. It creates commits with a special name that will be recognized `git rebase -i --autosquash`. It will merge commits with their fixups (+ whatever you want to do with `rebase -i`).
  - jakub_g 14y ago
    I was originally referring to fixing old typos (like spelling in documentation) that were in the repo forever. This, from what I understand this will take effect only if you introduced a typo recently and then you rebase so that the typo-containing commit is included in the rebase. Nevertheless, it sounds interesting.
- burntsushi 14y ago
  > Side hint: for things like fixing typos, I found that creating a new branch, say 'typos', is quite handy solution to not do these kind of things in the commits that are meant to add new things / fix bugs. Just checkout typos, fix, commit, checkout master / feature branch. Could you maybe elaborate on this a little bit more? I don't think I quite understand this. My understanding is that you'd have to do a 'git merge master' after you checkout 'typos', make the fix, commit, and then a 'git merge typos' after you checkout 'master'. Then wouldn't this add all of the typos commits into the master branch anyway? I'm very likely missing something fundamental. (Perhaps my source control habits aren't up to snuff.)
  - jakub_g 14y ago
    Yep I wrote this with too much shortcuts. What I do is: git checkout typos, git rebase master, [fix typo & commit], git checkout master. This way I accumulate typo fixes in a separate branch, and merge a couple of them at once to master when I see fit (perhaps squashing the typo commits into one beforehand).
masklinn 14y ago
Still unsolved: ensure your commits are not broken (aka pass all tests) without stashing everything else (in which case you could just as well stash the stuff you don't want in patch mode using `git stash -p`). (even if they are in a feature branch, broken commits will break `git bisect` unless the branch is folded when merged)
- Groxx 14y ago
  IIRC, you can clone the repo (leaving behind uncommitted changes) and run tests from that folder. Which also lets you run multiple tests in parallel if they're long, and continue to develop on your other branch, and ensures you have no absolute paths :) Cloning only takes a few seconds for even pretty large repos since it hardlinks everything.
- maaku 14y ago
  Not necessarily. Use patch mode (or a tool like GitX that does the same job), commit, then stash and run your tests. If it's broken, amend your commit, rinse and repeat. Then push your changes or pop the stash and continue development.
  - comex 14y ago
    If you're going to stash anyway, sounds better to use stash -p and run the tests before committing.
    - maaku 14y ago
      Or that ;) I just wish my git-GUI of choice (GitX) supported that mode...
  - masklinn 14y ago
    I'm pretty sure I specified > without stashing everything else and noted that if you're going to stash the rest either way you could just as well use `stash -p` in the first place.
    - 14y ago
bluesmoon 14y ago
Also use -v when committing to see the diff while writing your commit message
dpatrick86 14y ago
--word-diff is fun too
npsimons 14y ago
Ah, another "git -p" article. Funny thing is, I didn't even know about the "-p" option until I looked it up, even though I was using it all the time indirectly through Egg (Emacs Got Git). The sad part is, though, separating changes doesn't completely solve the problem (I often get lines overlapping between bug fixes, cleanups and new features). More than anything, discipline comes into it, but at least git makes it easier (especially with the fast branching). Another interesting take on Git's patch mode: http://tomayko.com/writings/the-thing-about-git http://tomayko.com/writings/the-thing-about-git

30 points by codenapper 14y ago

I'd suggest adding hunks instead of committing them so you can review your staging area at the end. It's the same flag; just use 'git add -p' instead of 'git commit -p'.

ujeezy 14y ago
And if you'd like to diff what's in the staging area, you can use this command: git diff --cached
codenapper 14y ago
Thanks, that's really helpful! I just updated the post.

deleted 14y ago

[deleted]

jakub_g 14y ago

FYI, in case you added reaaally a lot of stuff, and want to split it into smaller commits, it might be much more handy to do partial commits using Git GUI (select lines in the file & right click to have a popup menu with appropriate option). Also, don't do it the next time. Side hint: for things like fixing typos, I found that creating a new branch, say 'typos', is quite handy solution to not do these kind of things in the commits that are meant to add new things / fix bugs. Just checkout typos, fix, commit, checkout master / feature branch.

emillon 14y ago
For typos, `commit --fixup` is an invaluable tool. It creates commits with a special name that will be recognized `git rebase -i --autosquash`. It will merge commits with their fixups (+ whatever you want to do with `rebase -i`).
- jakub_g 14y ago
  I was originally referring to fixing old typos (like spelling in documentation) that were in the repo forever. This, from what I understand this will take effect only if you introduced a typo recently and then you rebase so that the typo-containing commit is included in the rebase. Nevertheless, it sounds interesting.
burntsushi 14y ago
> Side hint: for things like fixing typos, I found that creating a new branch, say 'typos', is quite handy solution to not do these kind of things in the commits that are meant to add new things / fix bugs. Just checkout typos, fix, commit, checkout master / feature branch. Could you maybe elaborate on this a little bit more? I don't think I quite understand this. My understanding is that you'd have to do a 'git merge master' after you checkout 'typos', make the fix, commit, and then a 'git merge typos' after you checkout 'master'. Then wouldn't this add all of the typos commits into the master branch anyway? I'm very likely missing something fundamental. (Perhaps my source control habits aren't up to snuff.)
- jakub_g 14y ago
  Yep I wrote this with too much shortcuts. What I do is: git checkout typos, git rebase master, [fix typo & commit], git checkout master. This way I accumulate typo fixes in a separate branch, and merge a couple of them at once to master when I see fit (perhaps squashing the typo commits into one beforehand).

masklinn 14y ago

Still unsolved: ensure your commits are not broken (aka pass all tests) without stashing everything else (in which case you could just as well stash the stuff you don't want in patch mode using `git stash -p`). (even if they are in a feature branch, broken commits will break `git bisect` unless the branch is folded when merged)

Groxx 14y ago
IIRC, you can clone the repo (leaving behind uncommitted changes) and run tests from that folder. Which also lets you run multiple tests in parallel if they're long, and continue to develop on your other branch, and ensures you have no absolute paths :) Cloning only takes a few seconds for even pretty large repos since it hardlinks everything.
maaku 14y ago
Not necessarily. Use patch mode (or a tool like GitX that does the same job), commit, then stash and run your tests. If it's broken, amend your commit, rinse and repeat. Then push your changes or pop the stash and continue development.
- comex 14y ago
  If you're going to stash anyway, sounds better to use stash -p and run the tests before committing.
  - maaku 14y ago
    Or that ;) I just wish my git-GUI of choice (GitX) supported that mode...
- masklinn 14y ago
  I'm pretty sure I specified > without stashing everything else and noted that if you're going to stash the rest either way you could just as well use `stash -p` in the first place.
  - 14y ago

bluesmoon 14y ago

Also use -v when committing to see the diff while writing your commit message

dpatrick86 14y ago

--word-diff is fun too

npsimons 14y ago

Ah, another "git -p" article. Funny thing is, I didn't even know about the "-p" option until I looked it up, even though I was using it all the time indirectly through Egg (Emacs Got Git). The sad part is, though, separating changes doesn't completely solve the problem (I often get lines overlapping between bug fixes, cleanups and new features). More than anything, discipline comes into it, but at least git makes it easier (especially with the fast branching). Another interesting take on Git's patch mode: http://tomayko.com/writings/the-thing-about-git http://tomayko.com/writings/the-thing-about-git