views:

46

answers:

1

I work on the same project on two different computers, desktop and laptop. Sometimes I need to transition between them while in the middle of some task/feature.

So I want to make a commit on the laptop, and then transport (push/pull) it to the desktop and continue. Then, when the feature is complete I want to make a new commit and then squash it with the half-done commit.

How can I now pull/push it back to the laptop without confusing the history?

What's the proper way of handling this? After doing this, I must also be able to publish the commits. Currently I'm working on the master branch directly, but if working on a separate branch helps I will do that.

I do know how to use git rebase -i, and have used it a few times while still on the same computer without a problem, so your answer does not have to include the details of git rebase/squash.

+2  A: 

I do this all the time and use the following workflow, using github as an authorative master repository when I'm not sitting at any given computer:

When I leave a computer i always do

 git push -f

When I arrive at a computer I do

git fetch -v
git reset --hard origin/master # Assuming branchname is master

As long as I always do the same, I know my latest work is always on github, and I rebase all I want

I generally also set

git config --global push.default current

to push only the branch I have checked out, something I find to be almost mandatory when using a lot of forced push.

krosenvold
I'm not sure I understand. I use github too. But don't you risk someone cloning your repo from github and then later you git push -f some modified history, wouldn't they get into problems then? I do actually have a third computer, a small server, where I also have a (private) clone of the repository. I guess I should be able to use that as an authorative master repository.
Anton
I don't fully understand 'git reset -- hard origin/master'. The documentation says it resets the current HEAD to the specified state. So if HEAD is local branch 'master', and that branch contains some old commits that have been rebased on the authorative master repository, what does it do? It make the local master refer to the same commit as the origin/master? And what happens to the old commits? When thinking single linked list, I guess they would be unreferenced and therefore not show up in, for example, gitk? Are they completely removed?
Anton
You can use any bare server-repository as authorative master. The effect of reset --hard is to just set your local checkout+index to *that* commit, effectively discarding local changes. That's why you always push when you leave a machine, so the master contains the last work you did. As for other collaborators, well, they'll have to follow your rebases, which beginners generally find hard
krosenvold