[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Savannah-hackers-public] Install a post-receive hook in the GNU Ema
Re: [Savannah-hackers-public] Install a post-receive hook in the GNU Emacs repository
Wed, 13 Jul 2022 17:35:20 -0600
Gregory Heytings wrote:
> Bob Proulx wrote:
> > I had written that first while loop some years ago for a different
> > multiple hook case. I therefore just reached for it and grabbed it for
> > this task.
> > But that doesn't mean that it can't do something different.
> The main reason was to minimize the network load on a (IIUC) already loaded
The CI server or the VCS server? (Rhetorical question! It was just
> And I see that the git_multimail.py script also handles the
> multiple lines case by itself. So I would suggest something like:
Ah! That's convenient.
[[ Inconveniently I notice that git-multimail.py is a python2 script.
Making me hope that the upstream version of it has been ported to
python3 as we don't need yet another obstacle to upgrading. ]]
> TMP=$(mktemp -u)
> cat - > $TMP
> cat $TMP | hooks/post-receive-git_multimail-emacs
> cat $TMP | hooks/post-receive-ci.heytings.org
> rm -f $TMP
Note that the reason the option is -u is because it is an unsafe
option. :-) It is definitely not desired in this type of context.
Also if we add temporary files then we would need to add signal
handling too. Temporary files and signal handling is all boilerplate
stuff. But that would make things significantly larger and over the
point where it would need a copyright statement added.
But let's crank up the tunes of Pink Floyd and We Don't Need No
Temporary Files, We Don't Need No Signal Handling here. :-)
I installed this latest iteration to the post-receive hook script,
leaving the others as previously noted.
printf "%s\n" "$lines" | ./hooks/post-receive-git_multimail-emacs
printf "%s\n" "$lines" | ./hooks/post-receive-ci.heytings.org
I think that should do it. Once again please let me know how I
screwed things up with this iteration. :-)
"lines=...anything..." is internal to the shell and therefore doesn't
require quoting since it is never expanded. So things like
lines=$(cat) are more efficient without quoting avoiding a temporary
Using $(...) always strips the trailing newline from the string. But
internal newlines are preserved.
printf "%s\n" "$lines" will print the internal newlines in the string
verbatim and then add on a newline on the end. One newline was
stripped and one added so things are back to zero sum total.
The size of this in memory is small. For example pushing two refs in
my testing generates two lines. Therefore reading that into memory
for that short script should be sufficiently small.