Why would you use Dropbox but also Git for your Emacs initialization file?_问答_开发者

I hear a lot of Emacs users have their init file (.emacs or init.el) under git version control and sync the git repository over Dropbox, when they run Emacs on multiple systems. Why would you use git in this situation exactly?

Usually checking which system you're on and which things to load and set depending on that can happen in one and the same init file for all systems. Why exactly would you want to save a version history of your init file, is it really that important that it justifies a git repository for it?

So, isn't it simply enough to put your init file in a Dropbox directory and load that one directly from Emacs directl开发者_开发知识库y instead of pulling the newest version from your synced git repo in Dropbox?

Git gives you version control, Dropbox gives you gratis private hosting.

Until recently, this was the only gratis method of hosting a private Git repo that I know of. Gitorious, repo.or.cz and Co. don't have private repos and GitHub, ShareSource and friends charge money for private repos. Assembla is the only hoster I know of that offers gratis private repo hosting, but that offering only started three weeks ago.

Personal configuration files might contain sensitive data, so it makes sense to host them privately, but it maybe doesn't make sense to pay GitHub 7$/mo just for one single .emacs file.

I use Dropbox not only for Emacs configuration files but also for all the other external packages (newer org-mode, SLIME, etc.) and individual .el files, so that I install and configure them (load path, info files, byte-compilation, etc.) only once for all the systems, and use Git to manage the configuration files (general setup, system or OS-specific customization).

After that, it's all downhill, as I put tons of reference material in my Dropbox (API docs, protocol stuff, cheat sheets, etc.) as well as development stuff (Java jar files, sources, etc.) so that I have the same development environment on all my systems with Emacs commands to access all the stuff.

As long as you think of your configuration files as code, you want to use a proper VCS. Dropbox gives some value, but it's not in the same league as git.

The short of it is that when you work with code, you want more than just to roll back to previous versions of the document. You want a quick and effective way to look at the differences between versions. You want to know what changed, why it changed, when, etc. You want to create experimental branches where you try something new without cluttering something you know works. You want to pull some of the changes from the experiment into your stable branch; but maybe not all of it.

Another issue is that in the future you might want to move your files, including all history, from Dropbox for some reason or other. If you use git, this is trivial.

Once developers find a version control system they like, there is a tendency to use it for all important files. -- You're ensuring that the files will always be backed up, managed, maintain a history (including log of comments, reasons for the changes, etc)

Git has attracted a lot of users, I'm not surprised to hear of people using it for tracking init files.

Dropbox gives you some history support, but it isn't as extensive and controllable as Git. If a developer knows Git, it makes sense for them to keep their configuration files for things like Emacs in Git. You have full versioning, you never lose an old version, you commit changes with meaningful messages at useful points in time, etc.

Now, why do it on Dropbox, when Git lets you push/pull between repositories? Simplicity. If your files are on Dropbox, they're transparently and automatically on all your Dropbox-connected computers. So you don't need to worry about "Have I pulled the changes? Where are the most recent changes?" etc. As others have mentioned, you also don't need to have a private Git repository somewhere, on your own server or a for-pay service.

Doing both also gives you the advantage of being able to easily clone your configuration to computers that do not support Dropbox easily (e.g. remote servers). Dropbox to sync to your laptop/desktop/workstation, git on the servers, and you have the same configuration everywhere with minimal hassle. And meaningful versioning.