I alias icommit="!git add -p && git commit -e -v" since i normally do the two together.
commit has gained a `-p` flag "recently".
Git add -p: a powerful git feature
51–60 of 108 posts
Re: Git add -p: a powerful git feature
#52For anyone using Mercurial, the hgrecord extension distributed with hg gives you the same feature - http://mercurial.selenic.com/wiki/RecordExtension
I can't remember the last time I used a naked commit; record has become part of my core workflow.
Re: Git add -p: a powerful git feature
#53So you end up committing untested code? (since you did test the whole change, not just part of it). Sounds like a bad idea to me.
Nothing wrong with committing untested code, it's pushing it as a ref one can reasonably expect people will merge/fast-forward to that it becomes a problem. git add -p is a nifty workaround for the type of people who don't like the workflow of "commit early, commit often" (some people have 'save file' bound to also make a commit) but who still want to have lots of small, contained commits.
Re: Git add -p: a powerful git feature
#54It's an absolutely fantastic (though dangerous) command. It's also a good illustration of how git doesn't commit anything you don't want to see committed (eg, "git commit" doesn't do anything if you haven't done "git add" before, letting you prepare your commits more carefully than with other VCSs).
You really need to test the version of the code you are going to commit. See the comment about using "git stash" elsewhere in this thread.
You need to test the version of the code you are going to publish, and unless you are publishing every time you commit, you don't need to test each commit.
I use git add -p whenever I've made too many changes between commits. I like for my commits to be of a single topic if possible.
If I use git add -p to break up a commit into 10 separate chunks, and find out something is broken, it's not hard to find the commit that caused the issue (if the commits are topical and not mixed).
Re: Git add -p: a powerful git feature
#55Re: Git add -p: a powerful git feature
#56Or just use gitx (or git-cola on Linux, or git gui if there's nothing better) and get a much better visual reference and easy of use. Not everything needs to be done from the command line.
Re: Git add -p: a powerful git feature
#57Git's "add -p" ui is great. If you're stuck on another VCS you might want to check out http://porkrind.org/commit-patch/ which, through the "commit-partial" command, lets you review and edit your patch before committing. It works with many of the open source VCSes out there.
I tend to use it even for git just so I have a consistent interface no matter what project I'm working on.
Re: Git add -p: a powerful git feature
#58Or you could just use a GUI app and save yourself a lot of time. SourceTree (OS X only, free - http://sourcetreeapp.com) has changed the way I use git since I started using it a few weeks ago.
The best thing is the discoverability - you don't need to know about the -p flag, for instance, since it's handled by the UI. Same for many other useful git commands that are hard to remember - they are often a simple option on a right-click menu, or a checkbox when performing an operation.
Re: Git add -p: a powerful git feature
#59When preparing a series of commits in a branch, what is the recommended method for editing non-HEAD commits? I know how to git commit --amend the HEAD commit, but how would one modify an earlier commit and rebase/replay the subsequent commits? git checkout the earlier commit and create a new branch from there?
In Mercurial, I would use an hg patch queue to hg qpop, qrefresh, then qpush.
Re: Git add -p: a powerful git feature
#60When preparing a series of commits in a branch, what is the recommended method for editing non-HEAD commits? I know how to git commit --amend the HEAD commit, but how would one modify an earlier commit and rebase/replay the subsequent commits? git checkout the earlier commit and create a new branch from there? In Mercurial, I would use an hg patch queue to hg qpop , qrefresh , then qpush .
"git rebase -i" is what is commonly used instead of hg patch queues. You pass it the name of the last unchanged commit, and it opens an editor where you define what operations to do on it : fold commits together (fixup, like qfold), stop for editing a commit, reorder them, change their description, etc.