Junio,
On Thu, Jun 19, 2014 at 11:29:21AM -0700, Junio C Hamano wrote:
> On Thu, Jun 19, 2014 at 11:03 AM, Junio C Hamano wrote:
> >
> > You chose to use the one that loses the information by unifying
> > these two into the variant that only returns -1/0/+1. We know that
> > it does not matter f
Junio,
On Thu, Jun 19, 2014 at 11:03:03AM -0700, Junio C Hamano wrote:
> Jeremiah Mahler writes:
>
> > Both unpack-trees.c and read-cache.c have their own name_compare()
> > function, which are identical. And read-cache.c has a
> > cache_name_compare() function which is nearly identical to
> >
On Thu, Jun 19, 2014 at 11:03 AM, Junio C Hamano wrote:
>
> You chose to use the one that loses the information by unifying
> these two into the variant that only returns -1/0/+1. We know that
> it does not matter for the current callers, but is it expected that
> no future callers will benefit b
Jeremiah Mahler writes:
> Both unpack-trees.c and read-cache.c have their own name_compare()
> function, which are identical. And read-cache.c has a
> cache_name_compare() function which is nearly identical to
> name_compare() [1]. The cache_name_compare() function is not specific
> to a cache,
Both unpack-trees.c and read-cache.c have their own name_compare()
function, which are identical. And read-cache.c has a
cache_name_compare() function which is nearly identical to
name_compare() [1]. The cache_name_compare() function is not specific
to a cache, other than by being part of cache.h
Version 4 of the patch series to cleanup the duplicate name_compare()
functions.
The previous patch series would have left the system in a broken state
if only part of the patches were applied. This version condenses all
the patches in to a single working patch as Jonathan Nieder suggested [1].
6 matches
Mail list logo
