7 ms·
My Git aha! moment was when I discovered "git add -p". I use it all the time now to break my work apart into multiple atomic commits.
by xbryanx 15y ago
My Git aha! moment was when I discovered "git add -p".
I use it all the time now to break my work apart into multiple atomic commits.
- telemachos 15y agoAgreed: don't know about you, but I picked that up from Ryan Tomayko's "The Thing About Git"[1] - some previous HN discussion on that, if anyone's curious[2]. [1] http://tomayko.com/writings/the-thing-about-git http://tomayko.com/writings/the-thing-about-git [2] http://news.ycombinator.com/item?id=158008 http://news.ycombinator.com/item?id=158008
- bostonvaulter2 15y agoI also like to use "git checkout -p" for the reverse; discarding working directory changes.
- underwater 15y agogit add -p That's "patch" for others who don't want to Google. Apparently can use it to choose which lines will be stored as the commit.
- masklinn 15y ago> Apparently can use it to choose which lines will be stored as the commit. The base UI is really for picking hunks (the sections you see in a `diff`), although git extended it to allow for splitting chunks into sub-hunks and ghetto-editing hunks. Other VCS and more details: * Darcs was probably the first VCS to implement this, it's the default behavior for `darcs record` (which is darcs's `commit` command). Much like git, darcs provides for full hunk edition (splitting hunks into sub-hunks, and removing or changing sections of hunks before recording them). * Mercurial provides this function through the (built-in) `record` extension. It currently gives no way to split or edit hunks, only to record or ignore them. The crecord third-party extension has these features (and/but a more complex, curses-based, UI) * `-p` is actually a subset of the much more complex `-i`/`--interactive`, which is a special staging-manipulation sub-shell. Note however that this is a powerfully dangerous tool, as it lets you commit untested revisions (then again, so does file-selection at commit, which has been available since SVN). Revisions created this way should be tested one by one for breakage, and rewritten if needed.
- zerd 15y agoThe problem is that if you do a partial commit, you have to test that it works. You may have forgotten to add one line, etc. One way to do this is to use "git stash save --keep-index", after patching. Then you can test that your program works with only that patch. After committing you can "git stash pop" to patch again or commit the rest. Maybe it's possible to make a hook to make this easier.
- Pistos2 15y agoI use git add -p to split apart what I intend to eventually fully get into the repo. Usually, this means separating whitespace cleanup from meaningful commits. Sometimes I use it to make my commits "distinctly describable" -- instead of a big commit saying (in effect) "I did lots and lots of stuff generally to do with BigTask", I am able to describe various steps of that work, e.g. "Refactored models.", "Added supporting .js file for foo mechanism.", "Migration for bar process.", "Controller method and view for baz form." Generally, I reserve the "make sure it works" step for just before _pushing_ (i.e. making public), rather than just before committing. I always use either `git commit -av` or `git add -p`, so I can preview what I'm about to do. I never use the freewheeling `git commit -m`.
- zerd 15y agoProblem with not testing your "micro-commits" is that when someone is looking at old revisions to figure out where something went wrong, there is a chance that it won't compile, or will crash because you didn't test that exact commit.
- Pistos2 15y agoI prefer smaller commits to larger ones because it isolates things (both improvements and breakage). I use git bisect when needed. You can always squash small commits into larger ones if really necessary, but teasing apart large commits into small, logical steps or components is much harder. Smaller commits are more "mobile" in that they can be cherry picked (in or out).
- davvid 15y ago
- anc2020 15y agoThis totally changed how I used git, wish I'd known about it from the start. Also emacs users should check out magit, which has a good 'add -p' and 'checkout -p' style of working