Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: >> Ah, perhaps our confusion comes from the fact that I view the ref >> API as a whole and do not draw a fine line of distinction between >> the "ref API implementation common across backends" vs "what ref >> files backend does". But as the implementor of one backend, you >> obviously have to care. > > Having the read function return something different than what the > write gets still seems odd to me. > How about having copy_reflog_msg() trim trailing space and then always add LF? > > The files backend can assert that the string ends in LF, and doesn't > need to add LF itself. Ehh, let's step back a bit. Is there anything in the common part and files backend in ref API that needs to be changed to fix some bug? I do not see anything broken that needs to be fixed by "assert that the string ends in LF and doesn't need to add LF itself" or by "always add LF".
