[14:45:45] jbarnes: my big beef with git add -p is it's not always granular enough [14:46:10] jbarnes: sometimes you can't split parts that are touching each other bug independent [14:46:15] *but [14:46:32] yeah you still have to do things by hand sometimes [14:46:39] but the split option worked for me this time [14:47:57] halfline: learn how to edit patches, that also works. [14:48:03] just don't forget to change the header... [14:48:26] i do edit patches too [14:48:26] you can use the edit option with add -p, and it give you instructions on editing the hunk. [14:48:33] but the real fix is "commit all the time" [14:49:30] anholt: the problem with edit is, what do you do remove the bits that you want to apply in a subsequent commit? [14:49:44] then you have to add them back manually afterward [14:50:15] halfline: I'm never splitting to more than 2 commits, so I don't see the problem. [14:50:19] really add -p would be perfect if you could split all the way down to the line level [14:51:00] anholt: yea i've learned to just commit early and often now to get around that problem [14:51:28] halfline: you're a born-again-committer [14:51:29] what you had in the tree is still there afterwards. [14:51:57] oga: you sure about that? i remember trying to use edit and it not being what i wanted [14:52:56] krh: that's right, i've spent too many hours splitting up large patches to fall into that trap ever again [14:53:05] when I used it this after noon to spit a smaller change out, yes [14:53:43] oga: okay i'll play with it again next time i have a need [14:54:03] if you're worried, a simple git diff > blah.diff before is an easy way to be sure. [14:55:21] yea [14:55:30] or stash or commit on a temporary branch