Hi, On Sun, 10 Jun 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Sat, 9 Jun 2007, Johan Herland wrote: > > > >> The text-based softrefs file format uses 82 bytes per entry (40 bytes > >> from_sha1 in hex, 1 byte SP, 40 bytes to_sha1 in hex, 1 byte LF). > >> > >> The binary softrefs file format uses 40 bytes per entry (20 bytes > >> from_sha1, 20 bytes to_sha1). > >> > >> Moving to a binary format increases performance slightly, but sacrifices > >> easy readability of the softrefs files. > > > > It is bad style to introduce one type, and then change it to another in a > > backwards-incompatible way. Either you make it backwards compatible, or > > you start with the second format, never even mentioning that you had > > another format. > > While I agree with that in principle, I think you are being a > bit too harsh to a set of patches that shows possible > alternatives for an idea that is not even in any unreleased > version of git. > > Got out of the wrong side of bed this morning? Possibly. Except it was not a bed, but an airplane passenger seat. And it did not help that I totally disagree with the approach: "sorted list does not do this well, unsorted not that... let's take both!" So, please take my words with a grain of salt. But I still think that _what_ I was saying is correct. Yes, the patch series shows an alternative, but I would have wished for either a smaller quick-n-dirty proof-of-concept implementation ([RFC]), or a better thought-through one ([PATCH]). Ciao, Dscho - 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
