Re: What's cooking in git.git (topics)

[Junio C Hamano <gitster@pobox.com>]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> * lt/dirstat (Tue Feb 12 17:06:58 2008 -0800) 2 commits
>>  - diff: make --dirstat binary-file safe
>>  + Add "--dirstat" for some directory statistics
>> 
>> The first one already in 'next' is the latest toy Linus showed
>> off in his 2.6.25-rc2 announcement.  The other one on top is a
>> rework to make it work more sensibly with a tree with binary
>> contents.
>
> Is this new one bytecount based rather than lines-changed based also
> for text files?

Short answer: Yes.

The issue in Linus's version is that the amount of change is
defined to be "number of lines added and deleted" for text files
while it is "number of bytes in preimage and postimage" for
binary files.  Summing them up and computing proportions among
them is comparing apples and oranges.

If you used line-based amount-of-change for text and byte-based
one for binary, you would be still comparing apples and oranges,
and you are not solving anything.  The scale used for all files
has to be consistent.

>> * br/gitweb (Fri Feb 8 14:38:04 2008 -0200) 1 commit
>>  + gitweb: Use the config file to set repository owner's name.
>> 
>> On hold per Jakub's reluctance.
> 
> It was tested by the author (Bruno Ribas) that it doesn't affect
> performance, although IMHO for a bit superficial test (1000 identical
> repositories, gitweb run as a script, dd or git-for-each-ref as an
> additional load).  I'd like to heard from larger gitweb deployments
> how it works with a webserver (ApacheBench or similar), with a real
> set of repositories, and perhaps in real load conditions... of course
> on test gitweb, not on live one.

I personally think the patch is Ok.  It would not affect really
large and loaded sites, because the top-level project list is
unusable for them without caching like John 'Warthog9' Hawley
does for k.org, due to other performance bottleneck (namely,
"the last changed timestamp") anyway.

By the way, I think "real load conditions" and "test gitweb not
live" are unfortunately mutually exclusive.  If it is known to
be "test", it will not attract the same set of "real" people as
the real one.

> I also wonder if it would make sense to make it a feature,

It might make sense, but it would not probably not help much in
practice.  It is overengineering, and I think it is spending
efforts in wrong place in the first place.

What I personally think the most important thing that should
happen to gitweb is to help cleaning up and updating John's
caching version that powers k.org, and update our version to
that.  John's version has seen a lot more real-life loads than
any other installation of the vanilla version in git.git, and we
should take advantage of his effort by slurping improvements
from his.  People who are both interested and have been involved
in gitweb might want to form a "gitweb-ng strike force" group,
and make a consolidated effort, just like msysgit folks do to
port our mess to Windows ;-).

>> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
>>  - Move all dashed-form commands to libexecdir
>>
>> Scheduled for 1.6.0.  I am not sure if we should merge this to
>> 'next' before 1.5.5.  Most active people will be on 'next' and
>> if we have this there, the resulting 1.5.5 release might end up
>> having issues that come from differences this one introduces.
>
> What about making separate libexecdir and moving _helper_ scripts
> (*--*) there first?

Why keep suggesting adding _more_ work, without any code nor
discussion of how that would help?