On Fri, Sep 13, 2013 at 6:16 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Eric Sunshine <sunsh...@sunshineco.com> writes:
>> Given the above. How should I proceed? Do you still feel that it is
>> advisable to keep an index_name_exists() around for compatibility
>> reasons in case any new callers are introduced? Regardless of that
>> answer, do you want index_name_exists() renamed to
>> index_file_exists()?
> Renaming *_name_exists() to *_file_exists() without keeping a
> compatibility one will force new topics to be rebased on this
> series.  Alternatively we could merge them to 'pu' (and later 'next'
> and 'master') with evil merges to adjust the change in the semantics
> of the called function.  That increases the risk of accidental
> breakages, I think.
> It is safer to keep index_name_exists() around with the older
> semantics, if we can, and rename your "file only" one to a different
> name.  That way, even if a new topic still uses index_name_exists()
> expecting the traditional behaviour, it will not break immediately
> and we do not need to risk evil merges making mistakes.
> Later, we can "git grep _name_exists" to spot them and convert such
> old-style calls to either "directory only" or "file only" variants
> after this series and these follow-on topics hit 'master' (and we do
> not know at this point in what order that happens).

Thanks. That's what I needed to know. I'll re-roll with the suggested changes.

(And, I'm looking into the Mac-only test breakages not related to this
patch series.)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to