Howto request: going home in the middle of something? v2009

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. I started looking around for a better way to do this, and came across a 2007 discussion (at http://kerneltrap.org/index.php?q=mailarchive/git/2007/10/18/347020/thread) where the OP really wanted (as do I) do be able to do something like this:

$ git stash $ git push $ git stash-push (travel to other site) $ git pull $ git stash-pull $ git stash apply (continue coding and committing as before)

There were a number of different suggestions, such as:

$ git commit -b temp -a -m "Hold for transport home"

Then when I get home I do this:

$ git fetch work
$ git merge work/temp
$ git reset HEAD^
 # code code code
$ git commit -b temp -a -m "Hold for transport to work"

When I'm finished at home and want to carry on at work:

$ git fetch --force home
$ git merge home/temp
$ git reset HEAD^
 # start coding for the day

... or using git-bundle

That discussion dates back to 2007. Is there a new, improved, 2009 way of accomplishing this?

--wpd

2009/4/21 Patrick Doyle <wpdster@gmail.com>:

man git-stash? or you can just git reset --soft HEAD^ away your wip commit.

On Tue, Apr 21, 2009 at 08:39, Patrick Doyle <wpdster@gmail.com> wrote:

Take a look at git-rebase command, particularly the interactive option, -i; this allows you to rewrite the history by removing commits, rearranging commits, and editing/amending commits.

Also, it seems like you're not branching enough.

On Tue, 21 Apr 2009, Patrick Doyle wrote:

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*