Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.

From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: Nov 16, 2008, 02:53 UTC
Message-ID: <cb7bb73a0811151853r418f02ear2f50518f89577054@mail.gmail.com>
In-Reply-To: <200811160213.43343.jnareb@gmail.com>

On Sun, Nov 16, 2008 at 2:13 AM, Jakub Narebski <jnareb@gmail.com> wrote:

Show 12 quoted lines

> On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
>> The initially intended purpose for this patch was to group remote
>> heads by remotes, but an interesting side-effect of doing it this way
>> was that it allowed to group _local_ heads too, by using the
>> stuff/morestuff syntax. For example, I could group gitweb/pathinfo and
>> gitweb/allheads together (although I disabled this grouping for local
>> heads in the patchset).
>
> I'm not sure if it would be that useful. How many people have _many_
> stuff/morestuff branches for some values of stuff/? The convention of
> <initials>/<topic> of topic branches in git.git doesn't usually lead
> to many branches with the same <initials>/ prefix.

Well, even if it's just two of them, it would still be nice. Or even better, we could make it so that the grouping is skipped unless there are at least N (to be decided) entries. This, btw, would be true for the remotes idea too.

Show 13 quoted lines

> Now I thought about it a bit, I think your solution has merit.
>
> Splitting by remotes is hard and difficult to do right, especially if
> you consider than 'remote' prefix doesn't need to have anything in
> common with names (common prefix) of refs/remotes/* remote-tracking
> branches used. It is fairly easy to do it right in common case, but
> hard in uncommon one.
>
> So perhaps the idea of using first dirname as a kind of category for
> remotes is a good idea. And usually it would be also remote name.
>
> But it really needs explanation in commit message... and quite a bit
> of commit squashing.

I'll probably do a single commit with a rather different logic than the current one, too.

Show 6 quoted lines

>> It would also probably be a good idea to separate the actual head
>> grouping from the display of the grouped head lists. I wonder if Perl
>> has a 'tree' data structure that could be used to store the grouped
>> head lists ...
>
> Hash of hashes (well, hash references), see perldsc(1)?

Ah, good, I always get those wrong. Will be an interesting challenge 8-D

Show 8 quoted lines

>> Would you say that in this case we want 'gsoc2008/gitweb-caching' as
>> the group head, or would you rather have nested groups [gsoc2008
>> [gitweb-caching [branches in gsoc2008/gitweb-caching] [etc]] ? I must
>> say that I think the latter would be quite interesting, but I _am_ a
>> little afraid we could turn up with way too much nested groups ...
>
> Now I think that having [gsoc2008] subgroup here might be a good
> thing...

And subgroups (one for each remote) therein?

My idea would be that, if you only have gsoc2008/gitweb-caching/branch[1-n], then you'd have a gsoc2008/gitweb-caching group, and branch1 ... branchn as entries. If OTOH we have gsoc2007/{gitweb-caching,gitstats}/branch*, we'd have gsoc2008 group with gitweb-caching and gitstats subgroups, each with its list of branches.

-- 
Giuseppe "Oblomov" Bilotta