So far I've mostly been ignoring how the command line would look
like, because the intermediate goal to my mind was to have it as a
hook that are added by people better versed with Git than an average
end-user, and if the command line interface had to change then they
are capable of updating it, so it is more acceptable than the usual
end-user tools to break compatibility between an early prototype and
later versions, and because the final goal would be to libify the
internal logic and integrate it into places we would invoke hooks,
making the standalone command irrelevant.
However, I started to care ;-) For example, wouldn't it be nice if
you can do
$ git format-patch -5 --cover-letter -o +my-series/ my-topic
$ git interpret-trailers "some args" ./+my-series/0*.patch
to fix-up the "trailers" portion of the proposed log message in the
formatted patches? There may be other possible uses that having a
standalone tool would be helpful, even after we removed the need for
such a tool from commit, rebase, etc. by integrating the internal
logic to the implementation of these commands.
However, I am wondering if the current "everything on the command
line is instruction to the command" is too limiting to allow the use
of the tool both as a filter and as a tool that can work on one or
more files named on the command line. If we start from there, the
only way to later add "these arguments are names of the files to be
operated on" is to add "--file <file1> --file <file2>..." options,
which feels quite backwards as a UNIX tool.
It would be easier to explain and understand if the command line
option set is modeled after things like "cat" or "sed", where
non-option arguments are filenames, instructions are given in the
form of "--option <arg>" (e.g. "-e 's/foo/bar/'" given to sed), and
having no non-option arguments on the command line signals that the
tool is working as a filter.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html