Re: [PATCH v2] send-email: export patch counters in validate environment

[Junio C Hamano <gitster@pobox.com>]

Robin Jarry <robin@jarry.cc> writes:

>  if ($validate) {
> +	# FIFOs can only be read once, exclude them from validation.

It is very good to see this comment here, as it may not be obvious
to everybody why we exclude them.

> +validate_cover_letter()
> +{

See Documentation/CodingGuidelines, look for "For shell scripts
specifically" and follow what is in the section.  There may be style
violations of other kinds in the file.

> +validate_patch()
> +{
> +	file="$1"
> +	# Ensure that the patch applies without conflicts to the latest
> +	# upstream version.

That comment is true only for the first one.  The second patch needs
to apply to the upstream plus the first patch, and so on.

> +	git am -3 "$file" || die "failed to apply patch on upstream repo"
> +	# XXX: Add appropriate checks here (e.g. checkpatch.pl).
> +}
> +
> +validate_series()
> +{
> +	# XXX: Add appropriate checks here (e.g. quick build, etc.).
> +}
> +
> +die()
> +{
> +	echo "sendemail-validate: error: $*" >&2
> +	exit 1
> +}
> +
> +get_work_dir()
> +{
> +	git config --get sendemail.validateWorkdir || {
> +		# Initialize it to a temp dir, if unset.
> +		git config --add sendemail.validateWorkdir "$(mktemp -d)"
> +		git config --get sendemail.validateWorkdir
> +	}
> +}
> +
> +get_upstream_url()
> +{
> +	git config --get remote.origin.url ||
> +		die "cannot get remote.origin.url"
> +}
> +
> +clone_upstream()
> +{
> +	workdir="$1"
> +	url="$(get_upstream_url)"
> +	rm -rf -- "$workdir"
> +	git clone --depth=1 "$url" "$workdir" ||
> +		die "failed to clone upstream repository"
> +}

Style-wise, it is better to get rid of get_upstream_url and write
the above more like

	workdir=$1 &&
	url=$(git config remote.originurl) &&
	rm -r -- "$workdir" &&
	git clone ... ||
	die "failed to ..."

and that would be less error prone (e.g. you will catch failure from
"rm" yourself, instead of relying on "git clone" to catch it for
you).

In any case, I would avoid network traffic and extra disk usage if I
were showing an example for readers to follow, and would not
recommend you to use "clone" here, even if it were a shallow one.

It would make much more sense to create a secondary worktree based
on this repository, with its HEAD detached at the copy of the target
branch (e.g. refs/remotes/origin/HEAD), and use that secondary
worktree, as the necessary objects for "am -3" to fall back on are
more likely to be found in such a setting, compared to a shallow
clone that only can have the blobs at the tip.

> +
> +# main -------------------------------------------------------------------------

> +workdir=$(get_work_dir)
> +if [ "$GIT_SENDEMAIL_FILE_COUNTER" = 1 ]; then
> +	clone_upstream "$workdir"
> +fi
> +cd "$workdir"
> +export GIT_DIR="$workdir/.git"

It is a good discipline to always set GIT_DIR and GIT_WORK_TREE as a
pair.  Working in a subdirectory of a working tree becomes awkward,
because the presence of the former without the latter signals that
your $(cwd) is at the top of the working tree.

But that is more or less moot, because I am suggesting not to use
"git clone" to prepare the playground and instead use a secondary
worktree that is attached to the same current repository, so GIT_DIR
would be the same as the current one.

And because you are "cd"ing there anyway, it probably is much
simpler to just 

    unset GIT_DIR GIT_WORK_TREE

to let the repository discovery mechanism take care of it.

> +if grep -q "^diff --git " "$1"; then
> +	validate_patch "$1"
> +else
> +	validate_cover_letter "$1"
> +fi
> +
> +if [ "$GIT_SENDEMAIL_FILE_COUNTER" = "$GIT_SENDEMAIL_FILE_TOTAL" ]; then
> +	validate_series || die "patch series was rejected"
> +fi

It is uneven that validate_patch and validate_cover_letter are
responsible for dying when problem is found, but validate_series is
not and the caller is made responsible for that.

I would make the caller responsible for dying with message for all
three by removing the calls to "die" or "exit" from the former two,
if I were showing an example for readers to follow.

Overall, a very well crafted patch, even though little details and
some design choices can be improved.

Thanks.