Stefan Monnier <monnier@iro.umontreal.ca> writes: > E.g. I can't see a clean way to install `git-commit` directly from its > VCS (i.e. recognized by `package-activate-all` and running from the Git > clone) without either forcing the install of `magit` at the same > time(&place) and/or having side-effects like sometimes shadowing another > installation of `magit`. I see what you did there. ;) This is an unusual, and in a sense extreme, example. Prescient is a much more typical example, so if you want to discuss the negative effect that such practices have on your workflow, then it would be better to focus on that package. git-commit/magit also has an unpleasant backstory. I can tell you about that in a private message. All I'll say here is that I did not actually want to add git-commit to magit but the behavior of its author forced me to accept the offer to take over as maintainer. At the time it seemed best to do that by adding it to the magit repository. Moving it to a separate repository is an option. At this time there aren't many changes that touch it, as well as other parts of the repository, so the cost would probably be pretty low, and I have done the same for with-editor and magit-popup (now replaced by transient) before. On the other hand, I have some doubts this is actually going to benefit anyone. Is there anyone out there who does use git-commit but not magit?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4