| Date | Commit message (Collapse) |
|---|
|
Apparently, --subject doesn't work[1] with "git send-email" in
this context. So drop the CLI arg and add a note to tell the
user to set a "Subject:" line in their response body, instead.
[1] I'm not sure if --subject ever worked as I thought it would,
or if it's a regression. In either case, there are current
versions of git where it doesn't, so just tell users to use
the currently supported method.
Link: https://80x24.org/lore/git/CAC4O8c-Tf11CpwuRudyrpXv5bGshuyEenV9kKrs0zRWER-+yHA@mail.gmail.com/
|
|
It's probably not a perfect match for RFC 6068 atm, but perfect
is the enemy of good.
Reported-by: Moritz Poldrack <moritz@poldrack.dev>
Link: https://public-inbox.org/meta/CKJSWGSZFKMX.3VUSIYE955Z9X@Archetype/
|
|
For /all/ (extindex) and like, Message-ID reuse from client
errors or list-injected footers can cause threading weirdness.
Avoid auto-vivification in the mapping table and dereferencing
of unknown messages.
|
|
A user may wish to clobber/refine existing search parameters
by issuing "lei q --save" again. Support that by overwriting
the lei.saved-search state file entirely.
We continue to preserve over.sqlite3 for deduplication purposes.
This way, we don't get something redundant like:
[lei]
q = term1
q = term2
q = term1
q = term2
q = term3
...whenever a user wants to refine their search. Instead,
we'll just have:
[lei]
q = term1
q = term2
q = term3
On the second go.
|
|
I keep copy-pasting the addresses provided,
I keep writing my plaintext reply in a file,
and I keep forgetting to add a subject
(because I am "just" writing a plaintext file)
Teach `git-send-email-reply` to append a `--subject` line.
[ew: avoid URI-encoded subject on command-line, adjust t/reply.t]
Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
|
|
Using "make update-copyrights" after setting GNULIB_PATH in my
config.mak
|
|
We need to escape ampersands (and some other characters for href
attributes), so introduce a `mid_href' sub to do just that.
'<', '>' and '"' were always escaped, so there's no risk of tag
or attribute injection, but creative Message-IDs could cause
confusion for some parsers and generate invalid URLs.
Start getting rid of the bloated, over-engineered OO Hval API
while we're at it, I only noticed this bug because I started
killing off Hval->new* callers.
|
|
I didn't wait until September to do it, this year!
|
|
|
|
Hopefully this helps people familiarize themselves with
the source code.
|
|
This can be useful for configuring archives of lists which are
no longer active.
|
|
Using update-copyrights from gnulib
While we're at it, use the SPDX identifier for AGPL-3.0+ to
ease mechanical processing.
|
|
Namely, we do not want to obfuscate the mail address of the
site itself.
|
|
This makes the wording less confusing when showing archives
for lists where the convention is reply-to-list.
I still hate reply-to-list, but it's still better than no
archives or list at all.
|
|
We can show users a lightly-obfuscated Bourne shell command
for invoking "git send-email" for address obfuscation. However,
I'm not sure if the mailto: arg will work effectively since
URL encoding is probably too well-known to be effective.
|
|
Reply-To is common and probably should've been supported,
since day one, but we won't omit other addresses, either.
|
|
This allows us to support centralized mailing lists (which suck,
but better than no mailing list at all).
|
|
We'll be adding more reply options for centralized mailing
lists. So split out the logic so it's easy-to-find.
Organizing code is hard :<
|