emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding git-commit highlight mode?


From: Konstantin Kharlamov
Subject: Re: Adding git-commit highlight mode?
Date: Sat, 04 Jan 2025 04:45:31 +0300
User-agent: Evolution 3.54.2

On Sat, 2025-01-04 at 03:22 +0200, Björn Bidar wrote:
> Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:
> 
> > On Fri, 2025-01-03 at 23:14 +0200, Björn Bidar wrote:
> > > Jim Porter <jporterbugs@gmail.com> writes:
> > > 
> > > > On 1/2/2025 10:30 AM, Konstantin Kharlamov wrote:
> > > > > But Emacs seems to be the only widely popular editor that
> > > > > still
> > > > > doesn't
> > > > > provide OOTB at least syntax highlight for git-commit format.
> > > > > So,
> > > > > does
> > > > > anyone have opposition to adding a major mode that would be
> > > > > bound
> > > > > to
> > > > > filenames like `COMMIT_EDITMSG` and others, and would provide
> > > > > the
> > > > > aforementioned highlight?
> > > > 
> > > > For what it's worth, I wrote a very simple package to do this
> > > > for
> > > > myself, since I don't use Magit. (I'm just so used to the Git
> > > > command
> > > > line that I've never taken the time to mess with Magit.)
> > > > 
> > > 
> > > Is there a way we can do this without reinventing the wheel? E.g.
> > > by
> > > including Jonas's git-commit mode into Emacs?
> > 
> > Using Jim's mode comes as close as it gets to not reinventing the
> > wheel. As mentioned by Stefan elsewhere in the thread, Jonas' git-
> > commit that is part of magit can't be easily included for license
> > reasons.
> 
> Most of the code was written by Jonas. If either the other authors
> code
> is replaced or they have also assigned their copyright to the FSF it
> could be included.

If you open this link
https://github.com/magit/magit/blame/main/lisp/git-commit.el and look
at the "contributors" text, it says "24". I think contacting 23
different people is so much work that you can rewrite the syntax
highlight 5 times and still get spare time.

> > > PS: It would be very beneficial to not uses Github for Emacs
> > > development but other FOSS platforms such as Codeberg. No need to
> > > feed
> > > Copilot with our code to copy it into other non-FOSS code.
> > 
> > As mentioned by Dick, Emacs is mirrored to Github anyway.
> 
> Dicks rather trolling comment aside, I don't think that is a reason
> to
> use Github.
> 
> > search it seems neither Codeberg nor Gitlab has an active Emacs
> > mirror,
> > right?
> > That means there's no other option besides Github for
> > contributors to store their local changes to before sending them
> > upstream.
> 
> I don't see a problem there, create an account on which server you
> prefer and fetch from Savannah.
> No need to use Github to download the Emacs repository.

I guess you're right.

> > Obviously, a new contributor wouldn't have an account to
> > git.savannah, and even if they do, git.savannah doesn't allow to
> > fork a
> > repo, instead it requires to store everyone the changes to their
> > local
> > branch on a shared repo, which seems unsafe on a bigger scale.
> 
> This has nothing to do with Savannah, you don't have to "fork" a
> repository that's a Forge thing to map pull requests (and to easier
> map
> commit refs between the source and the fork but that's OT).

Forking is a solution to the problem where you don't want to grant an
arbitrary person write access to a git repo. Though now that I think,
theoretically it may be possible to implement similar workflow by only
granting access to the `username/` sub-tree. Access management is done
by a harness around git, and one can write it any way they want. Either
way, I don't think such access management has been implemented by
anyone, whereas "forking" workflow does have implementations.



reply via email to

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