emacs-devel
[Top][All Lists]
Advanced

[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: Wed, 14 Aug 2013 23:46:10 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8

On 14.08.2013 22:02, Stefan Monnier wrote:
2) If packages/js2-mode and address@hidden: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.



reply via email to

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