Re: Git version of ELPA

[Dmitry Gutov <dgutov@yandex.ru>]

On 14.08.2013 22:02, Stefan Monnier wrote:
>>>> 2) If packages/js2-mode and git@github.com:mooz/js2-mode.git differ
>>>> in files they contain, I imagine we'll have more errors or conflicts
>>>> to deal with.
>>> Yes and no: the "push" would simply force the github version to have
>>> the same content as the elpa version.
>> The push just after the removal commit would end up fine.
>
> No, by definition "push" gives you an exact copy at the other end.

Yes, sorry. You're right, of course.

As long as you've resolved all the conflicts during the previous merge, 
and the remote head is a proper ancestor of the local head, the push 
will succeed.
Which, in the described situation, is arguably worse than failure.

>>> A simple solution is to not remove those files from the `elpa' branch.
>>> I.e. consider it as a "local change".  It might lead to spurious
>>> conflicts when merging, tho.
>> Not sure I understand. I didn't suggest removing them.
>> What changes, and "local" to what?
>
> Changes, as in "file removal", "file renaming", ...
> Local to the `elpa' version.

Ah, ok. I guess the "not" in "to not remove" above was a typo.

>> Exclusions are fine by me, too. So, file name ".elpaignore", syntax similar
>> to ".gitignore" (one glob per line)?
>
> Syntax: whatever "tar" accepts.

Sounds good.

Speaking of README file formats, maybe your current solution is good 
enough. The Melpa guys have intentionally settled on the same approach 
(use the Commentary from <package-name>.el):

https://github.com/milkypostman/melpa/issues/522
https://github.com/milkypostman/melpa/pull/366

The idea is that README.md/org/etc in the root of the directory serves 
as an introduction, and it usually contains a section "how to install".

The package description buffer, on the other hand, would be most useful 
if it has a short description of what the package is about and how to 
use it *once it's installed*.

I'm not sure if I fully agree with that reasoning, but doing readme 
generation the same way across package repositories would be good.