On Tue, Apr 09, 2024 at 06:02:49PM -0300, James Pond wrote:
> Hi,
> 
> As far as I know, and I just looked at the documentation again for good
> measure, there is no way to send GPG-signed patches with git-send-email.
> 
> However, I did find an interesting tool tool that integrates with it,
> patatt[1]. Might be worth looking into it. If nothing else, its README
> file explains why PGP-signed patches may not be a good idea.

That's what we use for Linux kernel development, to sign our patches
when sending them to mailing lists, and it works quite well.  Easy to
integrate with git send-email and very painless to check on the
receiving side as well.

On Mon, Dec 04, 2023 at 11:18:55AM +0100, Moritz Poldrack wrote:
> On Mon Dec 4, 2023 at 10:51 AM CET, Vlad-Stefan Harbuz wrote:
> > On 2023-12-03 at 16:03-08:00, Dev Email wrote:
> > > Some of my projects are licensed under MIT and Apache-2.0 license. In 
> > > this case,
> > >
> > > I include "LICENSE-MIT" and "LICENSE-APACHE" file in my repository. However,
> > >
> > > sr.ht does not seem to detect them, as I see this message:
> > >
> > >
> > I think support for LICENSE-MIT and LICENSE-APACHE is unlikely to be
> > added, because this is too specific — would this entail adding
> > LICENSE-GPL and so on for every major license?

On Tue, Aug 22, 2023 at 06:09:28PM +0100, Rose Hudson wrote:
> Hi all,
> 
> My friend and I moved our collaboration onto lists.sr.ht as a taster,
> and I've left with some strong opinions about the workflow, both good
> and bad :) I want to revel in the good ones, so I set about solving the
> things that drove us away, and I'm interested to know who shares these
> frustrations and what people think of my take on fixing them. The 
> project and its README are up at https://sr.ht/~roseh/patchy .
> 
> The main idea is to give semantics to subject lines - contributors can 
> then see how many Reviews are open, and maintainers can instruct that a 
> patch be Applied, etc., via mails with a certain subject prefix. With 
> this in place, Patchy being the sole applier allows it to check 

On Tue, May 24, 2022 at 10:56:08AM +0200, Rene Kita wrote:
> On Tue, May 24, 2022 at 07:19:12AM +0800, Beau Trepp wrote:
> > Hi All,
> > 
> > I've always loved the concept of collaborating more using email, and
> > absolutely love https://git-send-email.io/. This seems like a great
> > workflow for sending patches.
> > 
> > For the other half as a maintainer, I have gotten a bit lost.
> > I would be able to review code in my email client and respond, but I'm
> > not sure how to then get the commits or patches out of git and then
> > apply them to my repository to 'merge' in.
> 
> Here[1] is an interesting read from a kernel maintainer where he

On Tue, Jan 11, 2022 at 12:24:02PM +0100, hellekin wrote:
> On 1/11/22 10:04 AM, Jiri Vlasak wrote:
> > 
> > You mean like https://git.fsfe.org/reuse/tool ?
> > 
> 
> Yes, the REUSE (https://reuse.software) team put a lot of thought into
> licensing issues, notably that many repositories reusing code probably have
> more than one license to handle.
> 
> It would be great that sr.ht supports the LICENSES/ directory instead of the
> mainstream LICENSE files used by Git.

It does support it from what I can tell, I have a number of repos that

On Tue, Aug 17, 2021 at 12:16:16PM +0200, Drew DeVault wrote:
> The matter of license naming has come up before. Right now, we support
> something like 10 formats. It has been decided that we will not continue
> to expand our matching code to support every possible naming convention
> humans can come up with, and instead now ask projects to change their
> approach to conform to one of the existing patterns.
> 
> If your project has several licenses then I recommend merging them into
> one file with some prose which explains which license applies to what.

Nah, use the REUSE specification which puts all of the licenses into one
directory, LICENSES/, and then use proper SPDX lines at the top of each
file to refer to the proper license(s) that that file is released under.