Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 20, 2012, 18:03 UTC
Message-ID: <7vobtyfe06.fsf@alter.siamese.dyndns.org>
In-Reply-To: <87mx9icz28.fsf@thomas.inf.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

Show 8 quoted lines

>> More generally, scripts in t/ directories are "scripts", but it is totally
>> different from the kind of "user facing script that behaves as if it is a
>> complete command, taking its own command line arguments, passing them
>> through to the underlying plumbing commands".
>
> I don't understand what distinction you are trying to make here.  Maybe
> my mental model of the plumbing/porcelain separation (which is mostly
> about interface stability) is wrong?

What's so hard to understand that these tests are very different from end-user scripts?

We could have shipped you a written instruction to type these commands from your shell and made you responsible for running them every time we release a new version. That would have been more true to the intent of these test scripts. The test being implemented as scripts is merely a substitute for hiring one Thomas Rast as a test engineer to type them from the terminal ;-).

User-facing scripts (Porcelain enhancements) people write are in a totally different boat. They take input and have code to make their own decision what kind of arguments and inputs to feed to their underlying building blocks. They may even parse output from the commands they invoke to base their decision that affects what happens next. Our tests start from a known state (i.e. empty trash directory), take input from neither command line, human interaction nor the filesystem content of the day, that affect the input to the commands they drive.

To put it another way, if you have a cron job that does

    cd $HOME/diary && git add MyDiary.txt

that is perfectly fine. You are letting the machine do the typing for you every hour, instead of having you type these yourself. It is even OK if the filename was derived from `date` or something, i.e.

    N=$(date +'%Y-%m-%d').txt &&
    if test -f "$N"
    then
	git add "$N"
    fi

What is not OK is to attempt parsing from Porcelain output to decide what to do next. "git branch | sed -ne 's/^\* //p'" is a typical example.

Our tests are different for another important reason you seem to be missing. The tests we ship are tied very closely with the version of Git they are testing. Even parsing the command output is acceptable for our tests for this reason (obviously that is the only way to make sure that we are issuing an appropriate error, warning, or advice message to the end user). End-user scripts do not have that property.

And the biggest thing you should consider is that 99% of users are too busy to bother thinking for themselves and instead prefer to be handed down a concise recipe to follow blindly. You could include "in this, that, and that other situation, it is OK to use Porcelain command" to the recipe, but doing so defeats the whole purpose of having a recipe to begin with, by making the readers responsible for thinking for themselves again. That is why we just give a concise "Do not use Porcelain commands in your scripts as their behaviour is subject to change."