How to version control packages el-get has retrieved? (git submodule, subtree)

[mikavilpas]

I use el-get to fetch a bunch of packages from various sources on the Internet. My el-get configuration has worked well enough, but I recently spotted a fatal flaw in my design: when some of the sources of the packages I use are not available, my instance of emacs becomes unusable.

So instead of being truly portable, my configuration is dependent on a lot of stuff: for example the Internet connection and all required servers being online at the time my emacs instance is started.

I use git to manage my emacs configuration. What I'd like to have is a single git repository that stores everything my emacs needs to run. So my first thought is to add everything to a single big git repository. This, interestingly, seems really hard to do.

For me, el-get seems to add the retrieved stuff as git submodules, meaning I cannot directly see the changes in the package folders. But it seems I have no .gitmodules file, and there is no way to record the changes to my .emacs.d git repository.

What would you suggest? Am I doing it wrong?

[mikavilpas]

I experimented a bit with package.el, and it seems to store its received packages in a place that I can add and commit to my configuration repository. Maybe there already is a way to do the same using el-get?

Even if I switched to package.el completely, I wouldn't be able to get a maintainable configuration, since some packages I use are perhaps not in any usable repository. Besides, I wouldn't want to trade off el-get's single interface of an easily maintainable list of sources and packages chosen to be used.

[yyr]

I think Its more of a design choice (to be able to get any package from any where on the internet) and I agree that's a problem, especially when you try to port ".emacs.d" to new emacs installation.

MELPA catches and allows you to fetch from its repository rather than go wild on the internet for different packages.
(I see it as el-get on server side). So if you tell Melpa guys to catch another package for you, I think they will do it for you.

[DarwinAwardWinner]

I don't personally have experience using git submodules, but adding each git repo that el-get clones as a submodule of your main .emacs.d git repo seems like a reasonable idea. Like I said, though, I have no experience here, so I couldn't tell you how to actually do that.

But maybe it would be appropriate for el-get's git install method to automatically add git repos as submodules if it detects that the el-get directory is a subdirectory of a git repo.

[dimitri]

What about nested git submodules? Does that work? We would need support for that in order to even evaluate the merits of that idea...

[peterhoeg]

git supports nested submodules and checking them out as part of setting up the submodule with the --recursive parameter.

[dimitri]

So we can have el-get git packages registered as emacs.d git submodules even if they themselves use submodules, nice. What about svn or mercurial or other sources, will we check in the .svn subdirectories into that new git repository?

[mikavilpas]

For now, I use melpa / manual updating as a workaround.
Maybe el-get could handle the updating without submodules, so I could
directly check in the code to my main emacs.d repo?

[npostavs]

Maybe el-get could handle the updating without submodules

el-get doesn't use submodules, just plain repositories; but git ignores files in nested repositories, see http://git.661346.n2.nabble.com/nested-git-repos-not-submodules-td7271468.html

so I could directly check in the code to my main emacs.d repo

I think what's actually wanted here is git subtree, but it seems like a lot of work to get that done.

[mikavilpas]

Ah, that makes sense. Thanks for explaining.