On Sun, Nov 16, 2008 at 2:13 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> 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.
> 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.
>> 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
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
