Re: [PATCH] Change softrefs file format from text (82 bytes per entry) to binary (40 bytes per entry)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 10, 2007, 09:46 UTC
Message-ID: <Pine.LNX.4.64.0706101022210.4059@racer.site>
In-Reply-To: <7vir9w8b4a.fsf@assigned-by-dhcp.cox.net>

Hi,

On Sun, 10 Jun 2007, Junio C Hamano wrote:

Show 24 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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