Stefan Beller <sbel...@google.com> writes: > Presumably you merge the tip of this series (which contains 24/24) > with the other in-flight topics, that make new uses of > init_revisions(revs, prefix), which 24/24 allows. Going on either > parent side of such a merge will have working commits, that compile. > > So from that POV it doesn't matter when the #define is introduced.
But that is not a very interesting point of view anyway. > now and here, but at some later date, we would want to > 'git revert 24/24' after fixing all in-flights of today. No. We do not want to revert the whole thing. If the function that takes a_repository is called repo_rerere(), as opposed to just rerere(), it should keep that name after we deprecate the function rerere(). We will want to get rid of #define that gives a thin wrapper and make everybody use the API that requires a_repository parameter. And from that point of view, it is backwards not to introduce repo_rerere() when rerere.c gains a variant that can work in an arbitrary repository, not limited to the_repository, and fix it up saying "oops, we were wrong and this will break topics in flight" at the very end.
