Johannes Schindelin [off-list ref] writes:
On Sat, 9 Jun 2007, Johan Herland wrote:
quoted
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?
Hi,
On Sun, 10 Jun 2007, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Sat, 9 Jun 2007, Johan Herland wrote:
quoted
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