On Wed, Jun 11, 2025 at 11:55 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> From: Siddharth Asthana <siddharthasthana31@xxxxxxxxx>
> > + sed -n "/^author /s/\([^>]*>\).*/\1/p; /^committer /s/\([^>]*>\).*/\1/p" log >actual &&
>
> Perhaps just a matter of taste, but
>
> sed -n -e "/^author /s/>.*/>/p" -e "/^committer /s/>.*/>/p"
>
> may be easier to read and more portable (as some implementation of
> sed is picky about semicolon concatenated multiple commands).
For what it's worth, Git test scripts already contain a fair number of
uses of semicolon-separated `sed` commands, and we haven't heard of
any problems with them; not even from the very old and quite picky
Solaris `sed` (or was it the ancient SunOS `sed`?).
The only case I can think of in which there was a semicolon-related
problem (and perhaps what you're thinking of) was when a recent
patch[*] neglected to insert a semicolon where it was expected. That
particular case involved a missing semicolon before a closing brace:
sed -n '/ version /{p;q}'
which should have been:
sed -n '/ version /{p;q;}'
To summarize: Using semicolon-separated commands is safe and portable;
I don't think there is any evidence that doing so would be
problematic. Whether to use semicolon-separated commands or multiple
`-e` arguments is subjective, and I don't believe the project has
expressed a preference for one for or the other.
[*]: https://lore.kernel.org/git/CAPig+cR+ESNg4tV1G6jbKKeRKABD053qZcG0BoFuQ7aC+1tGYw@xxxxxxxxxxxxxx/
