Re: On "interpret-trailers" standalone tool

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 16, 2014, 17:43 UTC
Message-ID: <xmqq38hdi2zr.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAP8UFD0w9xUwuk9UZ_mu=qvjtYN1r5skidweruM8t1KbfQpQyA@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 5 quoted lines

> If the input comes from stdin, then I agree that the command should be
> a filter, so its output should be on stdout. But if the input comes
> from files given as arguments, then I would say that the command
> should behave as an editor and by default it should edit its input
> file inplace.

I do not see where that "should" comes from. I am looking at this more from the angle of obtaining a useful building block, while you seem to be thinking of this as a specialized tool for a narrow set of specifkc tasks.

Thinking of examples in "sort" and "sed", I would say "read multiple files, futz with the contents and spit out a single output stream" is the way people expect a command to operate without being told to operate in some other way. Overwriting existing files should never be the default for safety---otherwise you would require people who want safety to do something like:

    cp realfile tmp
    futz tmp
    verify tmp
    mv tmp realfile

On the other hand, a usual "sort/sed/cat"-like command, even without the "in-place edit" option, can be used as in-place with

    mv realfile tmp
    futz tmp >realfile

easily, and is more flexible as a building block. Of course, that does not rule out an option to work in-place (e.g. in a similar way to "sort -o file file", or "perl -i -e 'y/a-z/A-Z/' frotz nitfol").

Show 10 quoted lines

> Its input and output files should be different only if
> it is given one or more special option,
>
> Otherwise the example you gave:
>
>     $ git format-patch -5 --cover-letter -o +my-series/ my-topic
>     $ git interpret-trailers "some args" ./+my-series/0*.patch
>
> would result in having on stdout all the patches edited by "git
> interpret-trailers".

Didn't I mention that I do not mind "-i" already if in-place edit is desired? Add "-i" to the command line arguments among "some args", and your complaints will disappear, no?