unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Björn Bidar" <bjorn.bidar@thaodan.de>
To: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Cc: Jim Porter <jporterbugs@gmail.com>,
	 emacs-devel@gnu.org,  Jonas Bernoulli <jonas@bernoul.li>
Subject: Re: Adding git-commit highlight mode?
Date: Sun, 05 Jan 2025 02:46:32 +0200	[thread overview]
Message-ID: <20069.5380962983$1736038021@news.gmane.org> (raw)
In-Reply-To: <48c9115e57a6abd19b4465ab5d97d15301c395dd.camel@yandex.ru> (Konstantin Kharlamov's message of "Sat, 04 Jan 2025 04:45:31 +0300")

Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:

> 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.

Jonas replied to to this comment better than me already.

>> > > 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.

You misunderstand me: You don't have "fork" anything, just create new
repository with your desired name and fetch from which source you
prefer.
None of the "forking" workflow applies to Emacs development and fetching/cloning
of repositories can be done without "forking".
Just clone emacs.git and add your own remote, done.



  reply	other threads:[~2025-01-05  0:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-02 18:30 Adding git-commit highlight mode? Konstantin Kharlamov
2025-01-02 19:01 ` Eli Zaretskii
2025-01-02 19:07   ` Konstantin Kharlamov
2025-01-02 20:10     ` Stefan Kangas
2025-01-02 21:01       ` Eli Zaretskii
2025-01-02 21:38         ` Stefan Kangas
2025-01-03  5:26           ` Jim Porter
2025-01-02 21:40       ` Konstantin Kharlamov
2025-01-03  5:29         ` Jim Porter
2025-01-03 13:08       ` Jonas Bernoulli
2025-01-02 20:11     ` Eli Zaretskii
2025-01-02 21:19       ` Arsen Arsenović
2025-01-02 21:53         ` Stefan Kangas
2025-01-02 22:27           ` Arsen Arsenović
2025-01-03 21:02           ` Sean Whitton
2025-01-04  7:17             ` Eli Zaretskii
2025-01-04  9:52               ` Sean Whitton
2025-01-03  6:45         ` Eli Zaretskii
2025-01-02 19:17 ` Jim Porter
2025-01-02 19:19   ` Konstantin Kharlamov
2025-01-02 20:17   ` Eli Zaretskii
2025-01-03 21:14   ` Björn Bidar
2025-01-05 14:39     ` Philip Kaludercic
2025-01-05 22:48       ` Konstantin Kharlamov
     [not found]   ` <87r05jbnw2.fsf@>
2025-01-03 22:52     ` Konstantin Kharlamov
2025-01-04  1:22       ` Björn Bidar
     [not found]       ` <87v7uv9xub.fsf@>
2025-01-04  1:45         ` Konstantin Kharlamov
2025-01-05  0:46           ` Björn Bidar [this message]
     [not found]           ` <871pxiulxz.fsf@>
2025-01-05  3:55             ` Konstantin Kharlamov
2025-01-04 12:50         ` Jonas Bernoulli
2025-01-04 17:20           ` Jonas Bernoulli
2025-01-05  0:32           ` Björn Bidar
2025-01-05 18:47           ` Jim Porter
2025-01-05  0:42 ` Björn Bidar
     [not found] ` <875xmuum48.fsf@>
2025-01-05  3:49   ` Konstantin Kharlamov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='20069.5380962983$1736038021@news.gmane.org' \
    --to=bjorn.bidar@thaodan.de \
    --cc=Hi-Angel@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=jonas@bernoul.li \
    --cc=jporterbugs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).