Re: [PATCH v3 1/9] rebase -i: generate the script via rebase--helper

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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.