Using git and dropbox together
stackoverflow.com
stackoverflow.com
This way I can hack at work, hack at home, and hack on the plane... and I am never tempted to push one of those shitty "not done but committing because my flight to china is boarding" commits to the central repo (which is on a server accessed via ssh like normal).
It also saves my time because I don't have to git pull every time I switch computers in order to keep hacking where I left off.
That's a big, big win in my opinion, but it is just the same big win that Dropbox provides for various kinds of work. I don't see anything magical about the git+dropbox combo.
For people with multiple machines this is awesomeness. Everybody else still benefits from the extra backup layer of dropbox.
You know you can git commit to you local repo without needing an internet connection.
Branching in git is really cheap and easy compared to svn. A good way to work to always branch before starting anything. Work on that branch, commiting whenever you feel like. You don't need to push that branch unless someone else wants to work on the unfinished feature with you, or needs something from it before it is ready. In the meantime if the mainline moves on ahead you can just keep merging it into your feature branch to get the new changes. When it's ready you can then merge it back into the mainline and push that.
If you want to share a commit that isn't ready, it really should go on a feature branch and not the mainline. Then you can squash it into a real commit when its ready.
However, I prefer not to try to use a laptop for real work (because even the fastest laptops are much slower than a current Mac Pro). So, since I can't feasibly take my ginormous Mac Pro with me, as soon as I leave the office the repo on that workstation won't be my "local" one anymore.
Before moving my code into Dropbox, to avoid pushing something incomplete, I had to manually deal with transferring my local repo to the next computer(s) I was going to be working on it (typically that would mean copying the repo to a laptop for the plane, and then to a workstation at the destination).
That process was annoying and wasteful, and using Dropbox fixed that for me. Hooray!
This only happens when working on multiple machines.
Hopefully Dropbox will start syncing permissions soon.
I find git+dropbox particularly useful for non-public projects I work on on my own. I used to use a private github unfuddle repository and do a remote push, but now I just forget about the push and commit from within the dropbox folder.
The nice thing about Dropbox, and why I'm actually surprised this needs to be asked, is that it's completely transparent..it's just a folder. Create a project, git init and commit like you normally would.
What would happen if you had two MySQL servers running off the same data files in a shared Dropbox folder? Is that a good replication strategy?
Dropbox is for stuff, which needs to be synced but is (usually) not accessed concurrently. The programmer with the Dropbox-git will not code on two computers at once.
It was designed so it could be accessed via ssh for instance with multiple people pushing into at the same time.
The approach detailed here is totally unsuitable for team work; you will end up running into issues because you are handing the Git "server" off to a technology that is unsuited to handle it. You are much much better off, unless certain no one else will push at the same time, using a proper Git server.
The point of meeting these technologies is to give you the advantage of a personal shared workspace (amongst development machines) with the power of proper version control.
I can be playing around with a personal project at work.. and when I get home simply pick up where I left off if inspiration still grabs me. My productivity has gone up a noticeable amount.
1. http://www.errant.me.uk/blog/2010/04/a-nifty-way-to-manage-c...
What maintenance is there for git over ssh? And, git makes backups automatically :)
If you don't care about privacy, then you might as well just use github and have access to all of their cool collaboration features.
We employ teams of people to keep your code safe on GitHub.
I do like the idea of having a viewable copy of my git repo available, but to be honest I don't ever want to touch code if I can't git diff/commit
I hacked together a quick script to facilitate this (http://github.com/agnoster/git-dropbox), since it seems like one of those things where less friction potentially leads to significant changes in behavior.
git clone R R2
TL;DR: Git's hashing means that everything's going to be there, packing means that it's going to be a very inefficient sync (and you'll wind up with multiple copies of the same data) and branches may not behave as you'd expect.
ipad developers: Please give me a decent solution for code editing with git integration
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.
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.
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.
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.
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
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.