Re: [PATCH v2 24/24] Rename functions to avoid breaking in-flight topics

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 5, 2018, 21:04 UTC
Message-ID: <xmqq7ejz4pvq.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAGZ79kZhQJ7TbTuuDO_k-p80rGnOTjVcHf0aoq2+=pG4bwetNA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 6 quoted lines

> 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.