Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> In that case, I would strongly advise to consider redesigning the API.
The API we currently have and is used by "log", "rev-list" and
friends is to have setup_revisions() parse the av[], i.e. the
textual API, and it is sufficient to hide from the caller the
implementation detail of what bit rev_info structure has and which
bits are flipped when reacting to say "--format=..." option [*1*].
As the implementaiton detail of which bits are flipped when reacting
to each options is _not_ the API, we are essentially left with two
choices: write this series to the current textual API, or invent an
alternate API [*2*] and write this series to that new API.
Besides, the original was already using the textual interface to
set-up the revision traversal machinery (after all, it was a shell
script that invoked rev-list), and the series attempts a faithful
rewrite of it in C; writing to the current textual API is a
future-proof way to do so, and something you can do without waiting
for a new API to materialize (that is, assuming that we need an
alternate API, favoured over the current textual API).
[Footnote]
*1* You'll notice that there already are (and were in 2010) users
that cheated and peeked into the implementation detail by
looking at unnecessary places the patch that added pretty_given
bit; some of the places it needed to touch probably didn't have
to be touched if they were writing to the API and had their av[]
parsed.
*2* Quite honestly, I do not get how much you would gain dumping the
current API. It uses the same codepath "git rev-list" and
friends use to parse the requests by the end-users and scripts,
guaranteeing that it will stay stable, unlike the underlying
implementation that may and will change. And the set-up of the
machinery is not even the expensive part anyway.