[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Git version of ELPA

From: Dmitry Gutov
Subject: Re: Git version of ELPA
Date: Mon, 12 Aug 2013 19:23:43 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8

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:


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:
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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]