The win is the dropbox is free while github charge for private repos.

I have indirectly heard of someone writing a Javascript client for git using the http transport. It should be doable though a fair amount of work.

This is what I keep thinking as well. I think the difference is... when I want to switch to my laptop in a coffee shop, I have to push to github, regardless of what state the code is in. The build may be broken, a feature may be half implemented. I don't really like pushing with "sync to laptop" as the commit message.

So maybe dropbox is just meant to sync across your development area and github is still where the version control takes place?

If someone can elaborate on why they like this dual model, please let me know if I'm on the right track... or if there is a git-only solution that works as well.

When I'm moving stuff from work to home or the other way around, I'm usually committing my topic branch as far as I can using "clean" commits (doing one thing and only one), followed by one "temp: moving to home" commit.

Then I push to our Gitorious (not trusting github with company internal code, so preferring a self-hosted solution) which we use as a sandbox and/or for code reviews and discussion.

Then, at home, I pull and continue working.

Once the topic branch is completed, I rebase -i to edit and or squash to finally clean out that temp commit. Once I,'m happy, I push to our main repository (which is hosted using gitosis and works quite like a central svn repository where the whole team has push access and where we deploy from)

This works for me because I'm totally comfortable with rebase -i, add -i, squash and amend now so I can get rid of that temp commit.

If I weren't (some people refuse to rebase even on their topic branches and want to work exactly like subversion), then the dtopbox solution would be compelling because of that ugly temporary commit that I can't get rid of without rebase.

Push to your own fork of your project on github (if the project is not yours and you don't want to push incomplete things to the main repo), you can have multiple remote repos configured on your local clone and seamlessly switch and merge between them. Or if you don't want to fork, push to a work branch. That's why git has branching, forking and multiple remote repos features, it's not only a "version control system", it's a "distributed development system". Distributed means not only multiple people all working on one thing, but you also distributing your work.

This should do it, assuming you're on development:

  git checkout -b tmp
  git commit -a -m "throwaway"
  git push wherever tmp
  #switch machines
  git checkout development
  git fetch wherever 
  git merge wherever/tmp --no-ff
  git reset HEAD^
  git push wherever :tmp

and you could automate that with a pair of scripts.

Within git, branches are super-lightweight and easy to create. If you're coordinating with other developers (or finding yourself needing to shuttle code around between machines frequently) it would be worth creating a remote dev branch in your repo.

With a dev branch, you have the flexibility to just what you describe-- commit broken or half-completed code in order to move to another box-- and still clean up the commit or merge it with others before you move it to your "master" branch for deployment or sharing.

yeah, but then your logs and diffs get messy because you can't stage in hunks. or maybe I haven't grokked how. maybe `git merge stagingbranch -no-commit`?

Yes, you haven't grokked it. When you work on a development branch like this you can rewrite its history with git rebase --interactive before pushing your commits to the main branch.

You do have to be a bit careful not to introduce broken revisions as a part of your history-rewriting there, of course. Generally if you only use squash (which is sufficient to clean up "sync to laptop"-like changes) it won't be a problem though - it's when you start deleting or reordering commits that interesting things happen.

OF COURSE you can stage in hunks. That's why the index is so awesome in git.

Try git add -p (or -i, I prefer -p though) and you will see (and incidentally, never ever use commit -a any more)

And to alter commits before merging, use rebase -i and make use of the edit and squash options.

This workflow always seems backwards to me. "git add -p" lets me stage partial commits in the index, where I cannot build or test them. What I want to do is stage them into my working copy from somewhere else. I wonder how hard "git stash apply -p" would be to add....

Switch to a new branch before commiting, commit only what you want then switch back. Doing a git checkout -b new-branch-for-this-bit-of-code is quick and painless if you want to stage things while you're working, doesn't change anything since you're creating a new branch from your current point, and gives you much easier logging, diffing and merging capabilities later on. This is one of the recommended workflows for git, in fact.

You can also commit parts then stash the rest, test, pop the stash, commit more, stash, test, etc, etc. You can add things to commits with --amend, so you can tweak them if you notice something is missing after you added things with git add -p and then commited. I do this a lot when I want to split a commit and use git add -p.

If you really want to test things from somewhere else, use git new-workdir to create a new working dir based off your local clone. Whatever you stash or commit to one, the other will see, since they're really pointing to the same local git clone (if you look at the .git/ dir of a workdir, you'll notice it's all symlinks to the original clone). Just make sure every local workdir you create like this is on a different branch, otherwise it will get confused when you change things on one side (because, of course, they're all pointing to the same local clone, but suddenly the local files won't match). I use this to have a "test workdir", which is based on a clean and permanently updated branch, where I cherry-pick/merge from the work branch into it, build and test, without having to stash on my work branch, reconfigure things and otherwise stop the coding workflow.