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

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

[Patrick Doyle]

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

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

[Mikael Magnusson]

2009/4/21 Patrick Doyle <wpdster@gmail.com>:
> 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

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

-- 
Mikael Magnusson

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

[Michael Witten]

On Tue, Apr 21, 2009 at 08:39, Patrick Doyle <wpdster@gmail.com> wrote:
> But that leaves a bunch of "WIP" commits in my history.

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.

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

[Daniel Barkalow]

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*