On Wed, Dec 3, 2014 at 12:02 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > >> This way, callers can put the message in context or even avoid >> printing the message altogether. >> >> Currently hold_lock_file_for_append tries to save errno in order to >> produce a meaningful message about the failure and tries to print a >> second message using errno. Unfortunately the errno it uses is not >> meaningful because copy_fd makes no effort to set a meaningful errno >> value. This change is preparation for simplifying the >> hold_lock_file_for_append behavior. >> >> No user-visible change intended yet. >> >> Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx> >> --- >> The title feature. > > By the way, this seems to address the same thing as sb/copy-fd-errno > topic that has been cooking in 'pu'? Should we drop that other > topic and use this one instead? > This series makes the code more readable and maintainable in the end as we don't need to hunt down the path of when the errno is changed or accessed. The currently cooking sb/copy-fd-errno is more of a hot fix, while this series is fixing the problem more at the basic level and more in long term. I'd be happy if this replaces the currently cooking version. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html