[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Magit inclusion into GNU Emacs (was: Making git as easy as CVS, for
From: |
Dmitry Alexandrov |
Subject: |
Re: Magit inclusion into GNU Emacs (was: Making git as easy as CVS, for handling merge conflicts) |
Date: |
Sat, 02 Nov 2019 21:25:38 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Richard Stallman <address@hidden> wrote:
> Would someone like to do the work required to get Magit included in GNU
> Emacs? It has to do mainly with copyright assignments.
AFAIU, Jonas Bernoulli <address@hidden>, the maintainer of magit.vc, had
already stated a couple of years ago, that he is not much interested in
encumbering the development with copyright assignments:
| The primary downsides of assigning copyright to the FSF that I see is the
"waiting for papers to be signed" part and that some potential contributors
will no longer be able to / be willing to contribute.
| > Other than getting papers from contributors, are there ways in which Magit
becoming part of Emacs would significantly change the development workflow?
|
| I would probably get drawn into more lengthy discussions.
|
| It's important to note that when Richard said that Magit should be "part of
Emacs", that really meant "part of GNU Elpa and/or GNU Emacs". If Magit is just
made part of Elpa (which I believe is all that Richard wants), then that
doesn't change much. We get protection at the cost of the assignment overhead.
|
| But I already wanted to add parts of Magit to Emacs itself anyway. Low-level
libraries that are useful beyond Magit itself, and which would benefit from
being built-in. That includes some existing ui libraries but also new libraries
I intend to write to replace old abstractions used in Magit, such as a
file-handler for Git blobs and trees. Magit would benefit if other Git related
packages used those, instead of everyone reinventing the wheel.
|
| Once some code is part of Emacs itself it will be more difficult to change
than if it were living in a separate repository. On the bright side, that would
likely motivate me to write tools to make that process less painful.
— https://news.ycombinator.com/item?id=14819256
His position might get changed since that, though. Or yours.
signature.asc
Description: PGP signature
- Re: Making git as easy as CVS, for handling merge conflicts, (continued)
- Re: Making git as easy as CVS, for handling merge conflicts, Alexandre François Garreau, 2019/11/09
- Re: Making git as easy as CVS, for handling merge conflicts, Dmitry Alexandrov, 2019/11/05
- Re: Making git as easy as CVS, for handling merge conflicts, Richard Stallman, 2019/11/05
- Re: Making git as easy as CVS, for handling merge conflicts, Adam Spiers, 2019/11/06
- Re: Making git as easy as CVS, for handling merge conflicts, Richard Stallman, 2019/11/06
- Re: Making git as easy as CVS, for handling merge conflicts, Eli Zaretskii, 2019/11/07
- Re: Making git as easy as CVS, for handling merge conflicts, Eli Zaretskii, 2019/11/07
- Re: Making git as easy as CVS, for handling merge conflicts, Adam Spiers, 2019/11/07
- Re: Making git as easy as CVS, for handling merge conflicts, Eli Zaretskii, 2019/11/07
Re: Making git as easy as CVS, for handling merge conflicts, Richard Stallman, 2019/11/01
- Re: Magit inclusion into GNU Emacs (was: Making git as easy as CVS, for handling merge conflicts),
Dmitry Alexandrov <=