Junio C Hamano wrote:
quoted text
> Liu Yubao <yubao.liu@gmail.com> writes:
> 
> 
> A hint for understanding why loose objects are compressed is that
> packfiles were invented much later in the history of git.
> 
> These are both good questions, and it might have made a difference if they
> were posed in early April 2005.
> 
> At this point, the plain and clear answer to both of these "Why not"
> questions is "because that is the way it is and it is costly to change
> them now in thousands of repositories people use every day."
> 
> In other words, it is not interesting anymore to raise these questions
> now, especially as a suggestion to change the system, unless they are
> accompanied by arguments that convinces everybody that the cost of such a
> change outweighs the benefits, and a clear transition plans how to upgrade
> everybody's existing repositories without any pain.
> 

Thanks for your explanation, but I doubt if it's too costly to change the
format of loose object, after all this doesn't change the format of pack
file and affect git-pull/fetch of old git client. 

I ask the "why not" questions because I doubt if I miss some technical points
that the change isn't worth at all in fact.

If no severe technical problem will occur, I think it's worth breaking
*forward* compatibility for better performance and I'm willing to implement
it.

Some cons and pros.

cons:

* old git client can't read loose objects in new format
  (People degrade git rarely and old git can read pack files
   generated by new git, so it's not a big problem)

pros:

* avoid compressing and uncompressing loose objects that are likely
  frequently used when you are coding/merging
* share loose objects among multipe git processes
* the new code path is simpler although we will have more code paths for
  compatibility


Best regards,

Liu Yubao

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html