Re: [PATCH 1/3] name-hash: refactor polymorphic index_name_exists()

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 13, 2013, 22:16 UTC
Message-ID: <xmqqfvt8iczh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAPig+cS4x1h3v2=0T95+g2_08_7qZj7fUsSiLgDtFyRSbFE0bA@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 5 quoted lines

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

Hmm?