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
