Jeff King writes:
> This might provide an alternate solution (or vice versa). I kind of like
> this one better in that it doesn't require the sender to do anything
> differently (but it may be less robust, as it assumes the receiver
> reliably de-mangling).
I share the assessment. I also feel t
On Thu, Oct 10, 2019 at 12:41:32PM -0700, Jonathan Nieder wrote:
> > Add support for using the X-Original-Sender or Reply-To headers, as used by
> > Google Groups and Mailman respectively, to unmangle the From header when
> > necessary.
> [...]
> Interesting! I'm cc-ing the Git mailing list in ca
On 11/10/19 3:36 pm, Andrew Donnellan wrote:
It would be nice if Mailman could adopt X-Original-Sender too. As it is,
(which I have gone ahead and reported as
https://gitlab.com/mailman/mailman/issues/641)
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com I
On 11/10/19 3:29 pm, Junio C Hamano wrote:
Jeff King writes:
This might provide an alternate solution (or vice versa). I kind of like
this one better in that it doesn't require the sender to do anything
differently (but it may be less robust, as it assumes the receiver
reliably de-mangling).
On Fri, Oct 11, 2019 at 10:01:23AM +1100, Andrew Donnellan wrote:
> > This might provide an alternate solution (or vice versa). I kind of like
> > this one better in that it doesn't require the sender to do anything
> > differently (but it may be less robust, as it assumes the receiver
> > reliabl
On Fri, 11 Oct 2019 10:16:40 +1100 Daniel Axtens wrote:
>
> Andrew Donnellan writes:
>
> > On 11/10/19 6:41 am, Jonathan Nieder wrote:
> >> Interesting! I'm cc-ing the Git mailing list in case "git am" might
> >> wnat to learn the same support.
> > Argh, that reminds me... this patch only r
Andrew Donnellan writes:
> On 11/10/19 6:41 am, Jonathan Nieder wrote:
>> Interesting! I'm cc-ing the Git mailing list in case "git am" might
>> wnat to learn the same support.
> Argh, that reminds me... this patch only rewrites the name and email
> that is recorded as the Patchwork submitter,
On 11/10/19 9:54 am, Jeff King wrote:
Neat. There was discussion on a similar issue recently in:
https://public-inbox.org/git/305577c2-709a-b632-4056-658277117...@redhat.com/
where a possible solution was to get senders to use in-body From
headers even when sending their own patches.
I thi
Jonathan Nieder wrote:
> Eric Wong wrote:
> > Konstantin Ryabitsev wrote:
>
> >> This is actually really fast if you already have a local copy of the
> >> repository with most objects. Try this yourself if you have
> >> torvalds/linux.git locally:
> >>
> >> git clone --bare -s torvalds/linux.git
Konstantin Ryabitsev wrote:
> This is actually really fast if you already have a local copy of the
> repository with most objects. Try this yourself if you have
> torvalds/linux.git locally:
>
> git clone --bare -s torvalds/linux.git test
Yep, -s (--shared) makes cloning really cheap. One of my
On Thu, 10 Oct 2019 15:07:29 -0300
Mauro Carvalho Chehab wrote:
> Em Thu, 10 Oct 2019 10:41:50 -0400
> Konstantin Ryabitsev escreveu:
>
> > Hi, all:
> >
> > I would like to propose a new (large) feature to patchwork with the goal
> > to make the process of submitting a patch easier for newbie
Em Thu, 10 Oct 2019 10:41:50 -0400
Konstantin Ryabitsev escreveu:
> Hi, all:
>
> I would like to propose a new (large) feature to patchwork with the goal
> to make the process of submitting a patch easier for newbies and people
> generally less familiar with patch-based development. This was d
On Fri, Oct 11, 2019 at 08:38:49AM +1100, Daniel Axtens wrote:
Hi Konstantin,
tl;dr: I think a git-to-email bridge is a good step. I'm not sure why
patchwork would be the thing to build it on top of, and I'm worried that
it would slow us both down. I'm very open to being convinced though.
In v
Hi Konstantin,
tl;dr: I think a git-to-email bridge is a good step. I'm not sure why
patchwork would be the thing to build it on top of, and I'm worried that
it would slow us both down. I'm very open to being convinced though.
> I would like to propose a new (large) feature to patchwork with the
On 11/10/19 6:41 am, Jonathan Nieder wrote:
Interesting! I'm cc-ing the Git mailing list in case "git am" might
wnat to learn the same support.
Argh, that reminds me... this patch only rewrites the name and email
that is recorded as the Patchwork submitter, it doesn't actually rewrite
the From
Eric Wong wrote:
> Konstantin Ryabitsev wrote:
>> This is actually really fast if you already have a local copy of the
>> repository with most objects. Try this yourself if you have
>> torvalds/linux.git locally:
>>
>> git clone --bare -s torvalds/linux.git test
>
> Yep, -s (--shared) makes cloni
(+cc: git)
Hi,
Konstantin Ryabitsev wrote[1]:
> How I envision this would work:
>
> - user creates an account (which requires a mail confirmation)
> - they choose a "submit patch" option from the menu
> - the patch submission screen has a succession of screens:
Interesting! This reminds me a bi
On Thu, Oct 10, 2019 at 03:07:29PM -0300, Mauro Carvalho Chehab wrote:
- the patch submission screen has a succession of screens:
1. a screen with a single field allowing a user to paste a URL to
their fork of the git repository.
This will raise the bar, as it will force all developers
Hi,
Andrew Donnellan wrote:
> To avoid triggering spam filters due to failed signature validation, many
> mailing lists mangle the From header to change the From address to be the
> address of the list, typically where the sender's domain has a strict DMARC
> policy enabled.
>
> In this case, we
On Wed, 2019-10-09 at 18:44 +0200, Johan Herland wrote:
> Before I post v3, I'll wait for some more responses to the discussion
> on patch 2/3 about the best way (or rather: least horrible way) to
> determine the active user and forward it into the event creation.
I'll try do just that tomorrow. I
Hi, all:
I would like to propose a new (large) feature to patchwork with the goal
to make the process of submitting a patch easier for newbies and people
generally less familiar with patch-based development. This was discussed
previously on the workflows list:
https://lore.kernel.org/workflow
21 matches
Mail list logo
