Merge changes from GNU ELPA #408
Conversation
Most of these are minor issues involving, e.g., quoting `like this' instead of 'like this'. A few involve escaping ` and ' with a preceding \= when the characters should not be turned into curved single quotes.
|
Note that it's important to merge the metadata more than the contents, so please please pretty please don't squash it: |
|
@monnier To squash it would be to simply close the PR, since it doesn't bring in any useful code: (require 'ring) is already there, and the quote problems fixed in the docstrings were in generated test code. I'd really like to keep the linear commit history (no merge commits). I've done it for 7 years already. Is there a way to have auto-sync in GNU ELPA without merge commits? |
|
@monnier To squash it would be to simply close the PR, since it doesn't
bring in any useful code: (require 'ring) is already there, and the quote
problems fixed in the docstrings were in generated test code.
Good!
Is there a way to have auto-sync in GNU ELPA without merge commits?
The auto-sync only works if it can fast-forward, sadly :-(
|
|
Ping?
This problem is still preventing new releases of Hydra on GNU ELPA.
|
|
Re-Ping? |
|
Hello? Anybody there? |
Yes, it's possible: I've been manually merging That said, my vote is against insisting on an unconditionally linear history. |
|
> I'd really like to keep the linear commit history (no merge commits). I've
> done it for 7 years already. Is there a way to have auto-sync in GNU ELPA
> without merge commits?
Yes, it's possible: I've been manually merging `swiper.git` into `elpa.git`,
for example. I can volunteer to do the same for `hydra.git` if
given access.
FWIW, currently he GNU ELPA `hydra` package is configured with
`:merge t` so it does track the upstream branch even though it can't
do that via "fast forward". Of course, that works only as long as
there's no merge conflict.
Stefan
|
This merges the changes from GNU ELPA as discussed here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52902#8
Thanks!