git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3] gitweb: Add an option for adding more branch refs

From
Jakub Narębski <jnareb@gmail.com>
Date
Dec 2, 2013, 17:34 UTC
Message-ID
<529CC48C.5080902@gmail.com>
In-Reply-To
<1385985997.2054.27.camel@localhost.localdomain>
W dniu 2013-12-02 13:06, Krzesimir Nowak pisze:
Show 18 quoted lines
> On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
>> On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
>> <krzesimir@endocode.com>  wrote:
>>
>>> Allow @additional_branch_refs configuration variable to tell gitweb to
>>> show refs from additional hierarchies in addition to branches in the
>>> list-of-branches view.
>>>
>>> Signed-off-by: Krzesimir Nowak<krzesimir@endocode.com>
>>
>> Why not use %feature hash instead of adding new configuration variable?
>> I think that this option is similar enough to 'remote_heads' feature
>> (which BTW should be 'remote-heads'), and could conceivably enabled
>> on a per-repository basis, i.e. with repository configuration override,
>> isn't it?
>
> I'd like to see some consensus on it before I start changing the patch
> again.

%feature hash is mainly (but not only) about options that can be configured on per-repository basis. Configuration variables are about options that are per-instance (per gitweb).

Show 9 quoted lines
>> Usually %feature hash is preferred over adding new configuration variable
>> but this is not some hard rule. Note however that patches adding new config
>> are met with more scrutiny, as it is harder to fix mistakes because of
>> requirement of backwards compatibility of configuration files.
>>
>
> I don't know what kind of backwards compatibility you mention. Whether
> you want gitweb to survive reading old config file or to honor
> deprecated/old config variables.

I meant here honoring deprecated/old variables, i.e. honoring existing configuration files. See for example backward compatibility for old $stylesheet variable vs new @stylesheets in print_header_links().

Though in this case it shouldn't be much of a problem; it would be easy to honor @additional_branch_refs by setting 'default' for 'extra-branch-refs' feature to it.

>> BTW. there really should be gitweb/CodingGuidelines...
>>
>
> Yes, would be useful. As in every other project. :)

Well, Git itself *has* Documentation/CodingGuidelines, but perhaps gitweb subsystem should have it's own...

[...]
Show 44 quoted lines
>>> @@ -3662,7 +3701,8 @@ sub git_get_heads_list {
>>>                  my ($committer, $epoch, $tz) =
>>>                          ($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
>>>                  $ref_item{'fullname'}  = $name;
>>> -               $name =~ s!^refs/(?:head|remote)s/!!;
>>> +               my $strip_refs = join '|', map { quotemeta } get_branch_refs();
>>> +               $name =~ s!^refs/(?:$strip_refs|remotes)/!!;
>>>
>>>                  $ref_item{'name'}  = $name;
>>>                  $ref_item{'id'}    = $hash;
>>> @@ -7179,7 +7219,8 @@ sub snapshot_name {
>>>                  $ver = $1;
>>>          } else {
>>>                  # branches and other need shortened SHA-1 hash
>>> -               if ($hash =~ m!^refs/(?:heads|remotes)/(.*)$!) {
>>> +               my $strip_refs = join '|', map { quotemeta } get_branch_refs();
>>> +               if ($hash =~ m!^refs/(?:$strip_refs|remotes)/(.*)$!) {
>>>                          $ver = $1;
>>>                  }
>>>                  $ver .= '-' . git_get_short_hash($project, $hash);
>>
>> One one hand, it is about threating extra branch refs the same way as 'head'.
>> On the other hand we loose distinction between 'refs/heads/foo' and e.g.
>> 'refs/wip/foo'. But maybe that's all right...
>>
>
> In git_get_heads_list sub I could append a " ($ref_dir)" to refs which
> are in neither 'heads' nor 'remotes', so heads view would look like:
> master
> old-stable
> some-work-in-progress (wip)
> some-other-branch (other)
>
> where both master and old-stable are in refs/heads/,
> some-work-in-progress in refs/wip/ and some-other-branch in refs/other/.
>
> In case of branch snapshot names (snapshot_name sub) I could change it,
> so names for branches mentioned above would be
> "Project-master-<short-hash>.tgz",
> "Project-old_stable-<short-hash>.tgz",
> "Project-wip-some-work-in-progress-<short-hash>.tgz"
> "Project-other-some-other-branch-<short-hash>.tgz"
>
> What do you think?

That is, I think, a very good idea. Though perhaps it would be more readable to add this extra feature as a separate patch, on top of main one.

-- 
Jakub Narebski
Previous: Krzesimir NowakNext: Krzesimir Nowak
Message 6 of 12 in “gitweb: Add an option for adding more branch refs”
  1. gitweb: Add an option for adding more branch refsKrzesimir Nowak, Nov 28, 2013
  2. Eric SunshineNov 29, 2013
  3. Krzesimir NowakDec 2, 2013
  4. Jakub NarębskiDec 2, 2013
  5. Krzesimir NowakDec 2, 2013
  6. Jakub NarębskiDec 2, 2013
  7. Krzesimir NowakDec 3, 2013
  8. Jakub NarębskiDec 3, 2013
  9. Krzesimir NowakDec 3, 2013
  10. Junio C HamanoDec 2, 2013
  11. Jakub NarębskiDec 2, 2013
  12. Junio C HamanoDec 2, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.