On Tue, 21 Apr 2009, Patrick Doyle wrote: > Hello, > I've developed a work habit of keeping my source code repository on a > USB stick and carrying that back and forth with me between work and > home. (I typically have small, branchless, single-developer > projects.) When I arrive at the other machine, I do > > $ git pull > (code, commit, code, commit, etc...) > $ git push > > Occasionally at the end of the day (if I'm at work) or at the end of > the night (if I'm at home), I'm in the middle of something that I want > to continue, and I end up making a "work-in-progress" commit > > $ git commit -a "WIP" > > just so I can pull that in the next day/evening and continue where I > left off. But that leaves a bunch of "WIP" commits in my history. In general, it can be useful to make a sequence of WIP commits which you don't share with anyone else, and, when you've completed something, make a sequence of nice clean commits. One way to do that: $ git checkout -b wip # have a separate branch for the WIP $ git commit -m "junk" # this commit is total junk, but good hints $ git commit -m "stuff" # corrected a few things $ git commit -m "going home" # need to commit to have sometime to pull $ git commit -m "finally working!" # this is the first good state $ git checkout master # back on the real branch $ git diff master wip | git apply # get the good directory state $ git add -i # add only those changes that are a good first step $ git checkout . # get the working directory to match the first step $ make test # did you do it right? $ git commit # first production-quality commit $ git diff master wip | git apply # now get more changes ... $ git diff master wip | git apply # get remaining changes $ git add -i # notice that the remainder are noise, debugging, etc. $ git branch -D wip # throw out the bad changes In general, it's helpful to be able to commit any time you're about to make a change to something you've already changed (because your second change might not be as good as your first change), but then you want the public history to come from a later pass where you already know what you're doing and only make correct changes, so far as you can tell from having a working final result. It's like a painter doing a study before starting to paint the real painting. -Daniel *This .sig left intentionally blank* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html