Re: Git version of ELPA

[Dmitry Gutov <dgutov@yandex.ru>]

On 12.08.2013 18:24, Stefan Monnier wrote:
>> So, you've tried merging commits from upstream that include files not
>> present in ELPA? And splitting commits from ELPA to push them to upstream
>> repositories? And both work fine?
>
> Haven't tested any of them, since neither of them is supported by the
> current Bazaar setup: it can't be worse than what we have in this respect.

I'm making this emphasis because git subtree has been mentioned several 
times, and its apparent advantages include being able to merge in both 
directions. If you don't have external repos' histories, apparently 
splitting commits and pushing them back won't work:

http://stackoverflow.com/questions/5760331/git-subtree-is-not-retaining-history-so-i-cannot-push-subtree-changes-how-can-i

>>> Of course, if there's a better Git tree available, I'll happily switch
>>> to that one.
>> A little while back Jorgen wrote a recipe how to do that:
>> http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00235.html
>> I've yet to wrap my head around this git subtree business properly, but if
>> it helps, I can try to follow it myself, and publish the result.
>
> That would be nice.  I did not insist on it, because my tests showed
> that you can "subtree merge" an external branch after-the-fact: with
> Bazaar this resulted in serious problems, whereas with Git this is
> handled sanely (not as well as having the external branch merged
> right from the start, of course, but good enough).

With Bazaar, I always just copied the most recent versions of files in a 
package, more or less manually, then marked them in `vc-dir' buffer and 
committed the result as the new revision. I don't think that doing only 
a little better than that is good enough.

>> It raises a few questions, though. Up until now, the elpa branch has been
>> receiving its contents in preprocessed form:
>> 1) Some files and directories removed.
>> 2) -pkg.el files pre-generated and included.
>
> The `elpa' code will always tend to include local changes.  Less is
> better, but they're a fact of life.

Inside package directories? How necessary is that? If you mean bugfixes 
touching several packages at once, they should be prime candidates for 
splitting and pushing upstream (I think git subtree supports that, not 
100% sure).

On the subject of extra files, more specifically:
1) Can we do without README and -pkg.el files?
2) Can we handle having README.md (and probably other formats), 
.travis.yml, Makefile, extra dirs and .el files not meant for end users? 
Like `doc', `extras', `yasnippet-debug.el' and `yasnippet-tests.el' in 
the yasnippet repository on GitHub.

Probably not, but Melpa does this okay. Aside from not having to pull 
from hundreds of external repositories, I think ELPA should work the 
same way (but also retain and use the Version header values).

If implementing it is going to be a lot of work, are we willing to take 
package-build.el from the Melpa project and adapt it, or reuse some of 
its pieces? If maybe, do we care about copyright assignments for its code?

>> For example, just compare
>> http://repo.or.cz/w/emacs.git/tree/dbb5d60608ae6b99910b0c374f82b63fde526abf:/packages/yasnippet
>> and
>> https://github.com/capitaomorte/yasnippet/
>
> yasnippet is a problem, indeed.  Someone needs to sync up the two trees
> (and take responsibility to keep them in sync in the future).

We can try to ping Joao, but that's a separate issue.

My intention here was to illustrate the difference between the file 
trees, not between their contents.