
Using git and dropbox together - nreece
http://stackoverflow.com/questions/1960799/using-gitdropbox-together-effectively/1961515#1961515
======
veidr
I use git and dropbox together every day, but not like any of those people do.
I keep my code dir with all my projects in my (personal) dropbox. So that's
where my local 'working copy' repos live.

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.

~~~
dalore
Why are you pushing shitty "not done but commiting because flight is
boarding..." to the server? Surely they are only pushed to your local repo and
then squashed in a commit to the main server. Or worked out on a feature
branch then merged into the mainline?

You know you can git commit to you local repo without needing an internet
connection.

~~~
kayoone
i am still a svn user so i dont know exactly how git works, but how are you
supposed to get your data on your other machines if you dont push it to the
git server which is available from anywhere? Thats the point of syncing the
working copy with dropbox, so you dont have to get it manually from your work
machine. As i understand it git repos are local so my other machines wont have
access to that repo, or am i wrong ?

~~~
dalore
In git committing and pushing are two different things. With git you have a
copy of the repo, as does anyone else who checks it out. Think of each repo
like its own little svn server, everyone has one locally. So you can commit to
that and yes no one has access (unless you open it up to them, but no need to
complicate this). So you can commit your unfinished work without other people
seeing it, and still have history to be able to go back if necessary. Then
when it's ready you can push that back to the shared repo.

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.

~~~
jongraehl
I'm missing where you answered his question. He's talking about sharing his
latest edit to his other machines, which aren't permanently network connected,
without creating an explicit git version.

~~~
dalore
> 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.

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.

------
latch
There's a hump where people associate the push as something magical in version
control. While that may be true of some systems, in a distributed system the
commit is actually what's important.

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.

~~~
tomstuart
It needs to be asked because a Git repository is a database.

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?

~~~
beza1e1
Easy there! MySQL is something completely different. If relational database
replication would be as easy as Dropbox, then they would all support it out of
the box. Do NOT use MySQL on Dropbox!

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.

------
DTrejo
_You'll probably end up corrupting the shared bare repo. This approach is only
suitable for a small team (two in my case) where people can just shout over
their cubicle walls: "Hey! Nobody push! I'm pushing now!"._ – Ates Goral Sep
13 '10 at 20:04

~~~
xpaulbettsx
That's generally not as likely as you'd think - since the names of the files
are hashes of their content, the worst that can happen is you'll get dummy
files. Bob's 8331a5b is just as good as Sam's 8331a5b. You could conflict refs
(like where 'master' points to), but that window is generally pretty small.

~~~
skybrian
What about git repack?

~~~
bdonlan
git repack won't delete any files until it finishes creating a new packfile.
You might end up with a window in which the deletions are synced but not the
upload of the new pack - this means git operations from other hosts may error
out, but there'll be no permanent damage once the sync finishes. Additionally,
git won't delete orphaned objects in automatic GCs until a certain time period
passes - so no problem with concurrent commits. And if all else fails you can
always undelete every file under .git/objects through dropbox :)

------
ErrantX
I've been advocating something like this for ages (albeit I use Mercurial)
[1], it is a really really wonderful meeting of technologies. My approach is
slightly different; to use a remote repository for version control storage and
sync my development environment with dropbox. Some thoughts...

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...](http://www.errant.me.uk/blog/2010/04/a-nifty-way-to-manage-code/)

------
jshen
I don't understand this. It's very easy and cheap to get ssh access to a linux
box setup somewhere. git over ssh is easy and has the same basic setup as the
instructions in this link and it doesn't have the problems mentioned in the
link.

~~~
evandavid
I think the better all round solution (in terms of privacy, functionality and
maintenance) is to go with a free private git hosting provider like
assembla.com. I have tried both the dropbox solution as well as setting up
git+ssh on a vps, and assembla is now my goto for personal and side projects.

~~~
pilif
how is it better for privacy to use a private git hosting provider than _any_
other linux box you control?

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.

~~~
pjhyett
Because it's incredibly dangerous to think your machines are more secure just
because you own them. How much time per day do you spend making sure your
machine and everything on it is secure?

We employ teams of people to keep your code safe on GitHub.

------
ylem
What about using git and s3? Any thoughts on this? I've seen it done for both
java and python (dulwich I believe) implementations of git (as well as
hg)--but not cgit. Would one have to do this using webdav or fuse?

~~~
justincormack
Same issues with s3 with sync updates. Might be easier to work around as you
have etags but wont work out of the box.

------
CoachRufus87
i just placed my projects folder within the dropbox folder, and use github as
normal. perhaps i'm doing it incorrectly...

~~~
klochner
The state of your projects folder can change pretty rapidly when you check out
different branches. For some reason I'm not a fan of my dropbox folder
constantly trying to keep up with my branch changes.

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

~~~
agnoster
Ditto this - the idea of having the bare repo in Dropbox, but having my
frequently-changing stuff (especially, as you point out, with branch changes)
locally seems to me to be the sanest alternative.

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.

------
andrewaylett
While using git and dropbox might appear to work most of the time, and
shouldn't lose data, it's not an ideal pairing -- have a look at my answer to
this stack overflow question: [http://stackoverflow.com/questions/2199637/is-
this-plain-stu...](http://stackoverflow.com/questions/2199637/is-this-plain-
stupid-git-sharing-via-dropbox)

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.

------
tomstuart
The only completely safe way to do this is to have a detached work tree in
your Dropbox folder and your repository outside of it (i.e. set GIT_DIR and
GIT_WORK_TREE, or provide --git-dir and --work-tree/core.worktree). That way
each machine can automatically sync uncommitted work tree changes, which
avoids the "push a crummy commit because I'm leaving work / boarding a flight
/ on a boat" problem, but you still use the conventional Git mechanisms for
transferring objects between repositories, which avoids the "I'm afraid of
conflicting refs / repository corruption" problem.

------
_corbett
I do this myself... at first as a side effect as I work on any number of
machines and sync my entire home directory. but I got used to being able to
roll back to a recent version even if I somehow screwed up committing (has
saved me a couple of times, e.g. when I accidentally don't add a file to the
repo, assume it's there and it ends up deleted at some point). Although I
treat git exactly the same (I don't do any fewer or more commits/branches etc)
I enjoy the extra safety harness.

------
klochner
I don't see the win on top of github here, they're both "public" services, and
github is designed specifically to host git repos. With dropbox you commit and
wait for your code to sync; with git push you are synced as soon as the
command completes.

ipad developers: Please give me a decent solution for code editing with git
integration

~~~
drivebyacct2
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.

~~~
Calamitous
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.

~~~
dustingetz
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`?

~~~
avar
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.

~~~
bdonlan
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.

------
bkaid
I found this step by step guide useful as well for setting up git & dropbox:
[http://blog.wekeroad.com/danger-danger/git-and-dropbox-
sitti...](http://blog.wekeroad.com/danger-danger/git-and-dropbox-sitting-in-a-
tree)

