Johannes Schindelin schrieb: > FWIW GitTorrent may be implemented as part of git-daemon, if Sam's ideas > become reality. And then, sideband transport is _the_ means to do > asyncrounous communication while pushing bytes. I do not see how recv_sideband() in its current form could be helpful here (assuming that you really are thinking of sending binary data over band #2). > On Tue, 10 Mar 2009, Johannes Sixt wrote: >> Johannes Sixt schrieb: >>> For use-cases that you have in mind in GitTorrent, the *protocol* may >>> be a good choice, but the current implementation is definitely a >>> special case. >> And it really is: Did you notice that stuff that recv_sideband sends over >> the channel named 'err' (before my patch) has "remote: " prepended on >> every line? That's certainly not an implementation that you want if you >> send binary data over that band! > > Yes, that is unfortunate, but can be fixed easily. I don't believe this. Every treatment of "remote: " that you take away from recv_sideband() you must insert somewhere else. Perhaps easy, but certainly not as trivial as my patch. Just a reminder: You proposed to override write() on Windows in a non-trivial way, and we are discussing the topic above because I think that is not a good idea. The reasons are: - write() is a fundamental operation, and we should not mess with it out of caution. - Your proposal is not a catch-all. For example, combine-diff.c uses puts() in dump_quoted_path(). If your goal was to not touch code outside of compat/ then you need to override at least puts(), too. - All code that writes ANSI escapes should use fprintf() anyway. (Currently that is not the case, but all cases I'm aware of can be fixed trivially.) -- Hannes -- 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
