Submitting patches from magit

Submitting patches from magit

[dick.r.chiang]

I understand most of you use vc-mode to construct ChangeLog entries as per
CONTRIBUTE.

For the new-schoolers who use magit, I submit for consideration the
"magit-patch-changelog" package at https://github.com/dickmao/magit-patch-changelog.

Re: Submitting patches from magit

[Jonas Bernoulli]

Well that was confusing.  I am *right now* sorting my email and setting
up new rules.  So when "Submitting patches from magit" just appeared in
"emacs-devel", that very much looked like I just messed up.

On closer inspection...

> For the new-schoolers who use magit, I submit for consideration the
> "magit-patch-changelog" package at https://github.com/dickmao/magit-patch-changelog.

I'm afaid I haven't looked at it yet--still fighting imapfiler.  But it
sounds useful at least.


Hm.  I might as well ask here:

1. Why does that not work?

   netzone_move_list = function(mailbox, list)
     netzone.INBOX:move_messages(
       netzone[mailbox],
       netzone.INBOX:match_field('List', list)
     )
   end

   netzone_move_list('emacs-orgmode', 'emacs-orgmode.gnu.org')
   netzone_move_list('git', 'git.vger.kernel.org')

2. Can someone recomment a less painful alternative to imapfiler?

  Cheers,
  Jonas

Re: Submitting patches from magit

[Jonas Bernoulli]

> 1. Why does that not work?

Figured it out:
-        netzone.INBOX:match_field('List', list)
+        netzone.INBOX:contain_field('List-Id', list)

Also: in mu4e use "." to view the raw message.

Re: Submitting patches from magit

[Óscar Fuentes]

dick.r.chiang@gmail.com writes:

> I understand most of you use vc-mode to construct ChangeLog entries as per
> CONTRIBUTE.
>
> For the new-schoolers who use magit, I submit for consideration the
> "magit-patch-changelog" package at https://github.com/dickmao/magit-patch-changelog.

Much appreciated. What about optionally putting the changelog entry on
the commit message for those who have commit rights?

Please consider contributing this package to GNU Elpa.

Thanks.

Re: Submitting patches from magit

[dick.r.chiang]

ÓF> What about putting the changelog entry on the commit message?

Hum, I just read this tribal knowledge
https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00667.html
describing an "insider's" approach to changelog entries.

I suppose those who have commit rights find this method none too onerous.

As an "outsider" with a multi-file changeset, I've found wrangling changelog
entries for email submission tedious and highly error-prone.

A recent brouhaha discussing debbugs versus gitlab might also
have critiqued patch-based versus pull-request based development models, and
the efficacy of changelog entries.  It's the kind of thing that has been so
meticulously maintained for so many years that the old guard cannot be
faulted for wanting to preserve forevermore.  New-schoolers might counter with
the sunk-cost fallacy argument, however.

Re: Submitting patches from magit

[Óscar Fuentes]

dick.r.chiang@gmail.com writes:

> ÓF> What about putting the changelog entry on the commit message?
>
> Hum, I just read this tribal knowledge
> https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00667.html
> describing an "insider's" approach to changelog entries.
>
> I suppose those who have commit rights find this method none too onerous.

That's for VC-Dir. It doesn't work when committing changes from Magit,
does it?

Re: Submitting patches from magit

[dick.r.chiang]

ÓF> That's for VC-Dir. It doesn't work when committing changes from Magit,
ÓF> does it?

No.  My point was to express the confusion of new contributors lacking this
tribal knowledge when constructing a patch according to the exacting guidelines.

Preserving twentieth-century software practices has the nice side effect of
keeping out the "rabble" of youth, and the changelog requirement proves a natural
limiter to the number of changes an unvetted contributor might make.

Re: Submitting patches from magit

[Alan Third]

On Fri, Dec 20, 2019 at 08:18:51PM +0100, Óscar Fuentes wrote:
> dick.r.chiang@gmail.com writes:
> 
> > ÓF> What about putting the changelog entry on the commit message?
> >
> > Hum, I just read this tribal knowledge
> > https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00667.html
> > describing an "insider's" approach to changelog entries.
> >
> > I suppose those who have commit rights find this method none too onerous.
> 
> That's for VC-Dir. It doesn't work when committing changes from Magit,
> does it?

You can hit c in the hunks in the diff buffer to add them to the
commit message, but that gets old pretty quickly with a large change.

(For the record, it also doesn’t work right with Objective C code.)
-- 
Alan Third

Re: Submitting patches from magit

[Phil Sainty]

On 20/12/19 8:49 AM, dick.r.chiang@gmail.com wrote:
> For the new-schoolers who use magit, I submit for consideration the
> "magit-patch-changelog" package at https://github.com/dickmao/magit-patch-changelog.

Assuming this is only useful with Magit installed, would it make
more sense for it to be contributed to Magit?

-Phil

Re: Submitting patches from magit

[dick.r.chiang]

> Assuming this is only useful with Magit installed, would it make more sense
> for it to be contributed to Magit?

Maybe.  The package monkeys a magit menu to seamlessly insert itself, so
embedding within magit would actually *reduce* the lines of code.

But I suspect Mr. Bernoulli would not want such an emacs-devel-specific task
to be integrated into a fully general git porcelain.

Re: Submitting patches from magit

[Jonas Bernoulli]

dick.r.chiang@gmail.com writes:

>> Assuming this is only useful with Magit installed, would it make more sense
>> for it to be contributed to Magit?
>
> Maybe.  The package monkeys a magit menu to seamlessly insert itself, so
> embedding within magit would actually *reduce* the lines of code.

Instead of the magit-patch-changelog-initialize hack use:

  (transient-append-suffix 'magit-patch-create "c"
    '("e" "Create patches for Emacs" magit-patch-changelog-create))

Also don't fiddle with after-init-hook.  Just put this at the top-level.

> But I suspect Mr. Bernoulli would not want such an emacs-devel-specific task
> to be integrated into a fully general git porcelain.

Yes, I think this should remain a separate package.