Fredrik Gustafsson <iv...@iveqy.com> writes:
> Here we have two sh-scripts (git rebase
> and git am) interacting with each other.
> Both uses GIT_QUIET,
Correct.
> so if GIT_QUIET already is set by the caller (git rebase) the
> callee doesn't have to set it to.
Incorrect. "git rebase" invokes "git am", not dot-sources it, so it
does not propagate.
Both do dot-source git-sh-setup, which clears GIT_QUIET pretty
early, so even GIT_QUIET exported into the environment by mistake
will not affect them.
> However GIT_QUIET is undocumented for git-am (in Git Manual). If we
> translate git am to C/ruby/python/perl/etc. will we catch this?
I think it is irrelevant. git-am uses many shell variables,
e.g. HAS_HEAD, interactive, abort_safety, etc. but they are
implementation details of the program and there is no point
documenting it, and somebody rewriting it in C does not have to
stick to the same name.
What may deserve to be documented in Documentation/technical/
somewhere is the way how some shell variables (OPTIONS_SPEC,
OPTIONS_KEEPDASHDASH, LONG_USAGE, USAGE, GIT_REFLOG_ACTION, etc.)
are used in git-sh-setup, which is a collection of helper shell
functions for use in scripted Porcelains that dot-source it. It
allows the scripted Porcelains to say things like:
die "message"
say "message"
and the latter pays attention to GIT_QUIET.
> This raises a few more generall questions:
> do we already pass information between processes(!) with enviroment
> variables? And is this documented the way it should be?
There are a few used as implementation details, I think. GIT_QUIET
is not among them.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
