[email protected] writes: > From: Torsten Bögershausen <[email protected]> > > Break up the old 10/10 series about CLRF handling into smaller > series. This is a small bugfix, when merge.renormalize is used > with core.autocrlf (and no attributes are set).
Is it worth protecting the fix with a new test? Or does this flip an existing "expect-failure" to "expect-success"? > Prepare the refactoring to use the streaming interface. > Changes since v4: > - Rename #define in cache.h into HASH_USE_SHA_NOT_PATH > - convert.c: Rename has_cr_in_index into blob_has_cr() > Better logic when sha1 != NULL, > Adjusted the commit message > > Torsten Bögershausen (2): > read-cache: factor out get_sha1_from_index() helper > convert: ce_compare_data() checks for a sha1 of a path > > cache.h | 4 ++++ > convert.c | 34 ++++++++++++++++++++++------------ > convert.h | 23 +++++++++++++++++++---- > read-cache.c | 33 +++++++++++++++++++++------------ > sha1_file.c | 17 +++++++++++++---- > 5 files changed, 79 insertions(+), 32 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
