Minimalist public-inbox feed: sendmail-pi-feed

Minimalist public-inbox feed: sendmail-pi-feed

[Konstantin Ryabitsev]

Hi, all:

I was trying to create a "simplest possible" way to maintain a 
public-inbox developer feed, and this is the end-result:

https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/sendmail-pi-feed

It's written to be used with git-send-email, but can, theoretically, be 
used with any tool that accepts custom sendmail command paths (e.g.  
mutt) -- though if used in that capacity, it needs more features to make 
sure that private mail is not added to the feed. For example, there can 
be an "allowlist" of addresses to match against "to" or "cc".

At the moment, this is more of a proof of concept and I wanted to share 
it with you all for early comments. The main goal was to avoid 
introducing too many dependencies, such as perl and its many cpan 
modules, while producing valid public-inbox feeds -- so this script is 
literally 50 lines of bash. :)

From the readme section:

----
Simplest configuration is to set the following in your git config file,
either per repository, or globally in ~/.gitconfig if you want
a single developer feed for all your work.

[sendemail]
  smtpserver = /path/to/bin/sendmail-pi-feed

[sendemail "sendmail-pi-feed"]
  # the directory where to put the feed (will be created with --init)
  inboxdir = /path/to/toplevel/public-inbox-dir
  # if not set, the epoch will be 0, which is strongly suggested;
  # if you increment it for some reason, make sure you don't skip 
  # numbers
  epoch = 0
  # if defined, will pipe stdin to this command as well, in case
  # you want to actually send out the patches in addition to writing 
  # them to the public-inbox feed; leave undefined otherwise
  sendmail = /usr/sbin/sendmail

Once this is done, run "sendmail-pi-feed --init" to create the feed.
During the init process, you will be asked whether you would like to
PGP-sign the commits, which is strongly recommended if you already
have PGP-signing set up on your system.

After the --init is complete, you can use "git send-email" as you
normally would and all patches will be automatically added to the
feed. You can then publish the feed on any git hosting service by
setting a remote and performing a git push.

If you would like to auto-push the feed, you can add an appropriate
post-commit hook.
----

Thoughts?

-K

Re: Minimalist public-inbox feed: sendmail-pi-feed

[Eric Wong]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> Hi, all:
> 
> I was trying to create a "simplest possible" way to maintain a 
> public-inbox developer feed, and this is the end-result:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/sendmail-pi-feed
> 
> It's written to be used with git-send-email, but can, theoretically, be 
> used with any tool that accepts custom sendmail command paths (e.g.  
> mutt) -- though if used in that capacity, it needs more features to make 
> sure that private mail is not added to the feed. For example, there can 
> be an "allowlist" of addresses to match against "to" or "cc".
> 
> At the moment, this is more of a proof of concept and I wanted to share 
> it with you all for early comments. The main goal was to avoid 
> introducing too many dependencies, such as perl and its many cpan 
> modules, while producing valid public-inbox feeds -- so this script is 
> literally 50 lines of bash. :)

Cool.  Though it's doable with POSIX sh :)  I seem to remember
Ubuntu not installing bash by default, and I know git itself
hasn't require it since 2006 or so.

> From the readme section:
> 
> [sendemail "sendmail-pi-feed"]
>   # the directory where to put the feed (will be created with --init)
>   inboxdir = /path/to/toplevel/public-inbox-dir
>   # if not set, the epoch will be 0, which is strongly suggested;
>   # if you increment it for some reason, make sure you don't skip 
>   # numbers
>   epoch = 0

<snip>

> If you would like to auto-push the feed, you can add an appropriate
> post-commit hook.
> ----
> 
> Thoughts?

It could be confusing with "inboxdir" meaning slightly different
things between public-inbox itself and sendmail-pi-feed.

Perhaps start with:

diff --git a/sendmail-pi-feed b/sendmail-pi-feed
index 67c4668..c085410 100755
--- a/sendmail-pi-feed
+++ b/sendmail-pi-feed
@@ -52,7 +52,7 @@ if [[ -z $EPOCH ]]; then
     EPOCH=0
 fi
 
-PIGITDIR="$INBOXDIR/$EPOCH"
+PIGITDIR="$INBOXDIR/git/$EPOCH.git"
 PIGITDIR="${PIGITDIR/#\~/$HOME}"
 
 if [[ $1 == '--init' ]]; then


And then init --bare, add a worktree; or better,
use old-school plumbing to avoid porcelain surprises:

	# n.b. error-checking omitted
	GIT_DIR=$PIGITDIR
	export GIT_DIR
	head=refs/heads/master
	name=$(expr "z$AUTHOR" : 'z\(.*[^ ]\) *<.*')
	email=$(expr "z$AUTHOR" : '.*\(<.*\)')

	# no cat, no temporary file, no worktree, no index:
	blob=$(git hash-object -w --stdin)
	tree=$(printf '100644 blob %s\tm' $blob | git mktree)

	# check if it's the initial commit, or if there's a parent
	parent=
	if git rev-parse $head^0 2>/dev/null
	then
		parent="-p $head"
	fi
	commit=$(GIT_AUTHOR_NAME=$name \
		GIT_AUTHOR_EMAIL=$email \
		GIT_AUTHOR_DATE=$DATE \
		git commit-tree $parent -m "$LOGLINE" $tree)
	git update-ref $head $commit

Working off a bare repo has other benefits, too, in case the
user eventually wants to run "public-inbox-index" on it and
serve directly from their machine.

As for porcelain surprises, a "git commit" invocation w/o
"--no-verify" could trip some folks up because some users
have hooks to reject trailing whitespace via "git init",
and email signature delimiters have trailing space ("-- \n").