threads / rfc / 21975

RFC patchgitweb: link to toggle 'no merges' option

Subject: [RFC/PATCH] gitweb: link to toggle 'no merges' option

## tl;dr

5 messages between Dec 17, 2009 and Dec 17, 2009. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

Giuseppe Bilotta· Dec 17, 2009, 09:05 UTC · lore

In views that support --no-merges, introduce a link that toggles the option.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
 gitweb/gitweb.css  |   11 +++++++++++
 gitweb/gitweb.perl |   14 ++++++++++++++
 2 files changed, 25 insertions(+), 0 deletions(-)

This is something I've been wanting for a while. There are a number of things that don't 'click' with this proof of concept, and I'm coming to the list to hear the opinion of users and developers on how to improve the thing.

The patch is live at http://git.oblomov.eu/, an example affected page is http://git.oblomov.eu/git/shortlog

Things that are sure to change:
 * the aesthetics and location of the toggle link (it shows on mousehover
   in the title). Other options I've considered are:
    + next to pagination (first | prev | next), either before or after
      the existing entries
    + on mouseover for the table section that refers to the (short)log;
      this would make it possible to put it summary view too, for example
 * if you toggle merge view when not on the first page, the reference
   (first) commit in the view is likely to change drastically, which
   causes confusion. I have not found a satisfactory solution for this,
   since the obvious way to 'lock' the view (start paginating from the
   current top commit) prevents prev/next navigation
Show changes to 2 files +25 −0

gitweb/gitweb.css, gitweb/gitweb.perl

diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 50067f2..0da6ef0 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -572,3 +572,14 @@ span.match {
 div.binary {
 	font-style: italic;
 }
+
+span.merge_toggle a {
+	font-size: 66%;
+	color: white !important;
+	font-weight: normal;
+	vertical-align: top;
+	text-decoration:none;
+	visibility: hidden;
+}
+
+*:hover > span.merge_toggle a { visibility:visible }
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7e477af..a63f419 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3118,11 +3118,15 @@ sub git_header_html {
 	my $status = shift || "200 OK";
 	my $expires = shift;
 
+	my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
+	my $has_merges = !grep(/^--no-merges$/, @extra_options);
+
 	my $title = "$site_name";
 	if (defined $project) {
 		$title .= " - " . to_utf8($project);
 		if (defined $action) {
 			$title .= "/$action";
+			$title .= " (no merges)" unless $has_merges;
 			if (defined $file_name) {
 				$title .= " - " . esc_path($file_name);
 				if ($action eq "tree" && $file_name !~ m|/$|) {
@@ -3235,6 +3239,16 @@ EOF
 		print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
 		if (defined $action) {
 			print " / $action";
+			if ($can_have_merges) {
+				print " <span class='merge_toggle'>";
+				if ($has_merges) {
+					printf('<a href="%s">hide merges</a>', href(-replay=>1, 'extra_options'=>('--no-merges', @extra_options)));
+				} else {
+					my @href_extra = grep(!/^--no-merges$/, @extra_options);
+					printf('<a href="%s">show merges</a>', href(-replay=>1, 'extra_options'=>@href_extra));
+				}
+				print "</span>";
+			}
 		}
 		print "\n";
 	}
-- 
1.6.3.rc1.192.gdbfcb
Etienne Vallette d'Osia· Dec 17, 2009, 13:03 UTC · re: Giuseppe Bilotta · lore

Re: [RFC/PATCH] gitweb: link to toggle 'no merges' option

Oh, this is exactly what I wanted for a long long time... I hope this feature will be merged soon !

Le 12/17/2009 10:05 AM, Giuseppe Bilotta a écrit :
Show 89 quoted lines
> In views that support --no-merges, introduce a link that toggles the
> option.
> 
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> 
> ---
>  gitweb/gitweb.css  |   11 +++++++++++
>  gitweb/gitweb.perl |   14 ++++++++++++++
>  2 files changed, 25 insertions(+), 0 deletions(-)
> 
> This is something I've been wanting for a while. There are a number of
> things that don't 'click' with this proof of concept, and I'm coming to
> the list to hear the opinion of users and developers on how to improve
> the thing.
> 
> The patch is live at http://git.oblomov.eu/, an example affected page is
> http://git.oblomov.eu/git/shortlog
> 
> Things that are sure to change:
> 
>  * the aesthetics and location of the toggle link (it shows on mousehover
>    in the title). Other options I've considered are:
>     + next to pagination (first | prev | next), either before or after
>       the existing entries
>     + on mouseover for the table section that refers to the (short)log;
>       this would make it possible to put it summary view too, for example
> 
>  * if you toggle merge view when not on the first page, the reference
>    (first) commit in the view is likely to change drastically, which
>    causes confusion. I have not found a satisfactory solution for this,
>    since the obvious way to 'lock' the view (start paginating from the
>    current top commit) prevents prev/next navigation
> 
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index 50067f2..0da6ef0 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -572,3 +572,14 @@ span.match {
>  div.binary {
>  	font-style: italic;
>  }
> +
> +span.merge_toggle a {
> +	font-size: 66%;
> +	color: white !important;
> +	font-weight: normal;
> +	vertical-align: top;
> +	text-decoration:none;
> +	visibility: hidden;
> +}
> +
> +*:hover > span.merge_toggle a { visibility:visible }
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 7e477af..a63f419 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3118,11 +3118,15 @@ sub git_header_html {
>  	my $status = shift || "200 OK";
>  	my $expires = shift;
>  
> +	my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
> +	my $has_merges = !grep(/^--no-merges$/, @extra_options);
> +
>  	my $title = "$site_name";
>  	if (defined $project) {
>  		$title .= " - " . to_utf8($project);
>  		if (defined $action) {
>  			$title .= "/$action";
> +			$title .= " (no merges)" unless $has_merges;
>  			if (defined $file_name) {
>  				$title .= " - " . esc_path($file_name);
>  				if ($action eq "tree" && $file_name !~ m|/$|) {
> @@ -3235,6 +3239,16 @@ EOF
>  		print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
>  		if (defined $action) {
>  			print " / $action";
> +			if ($can_have_merges) {
> +				print " <span class='merge_toggle'>";
> +				if ($has_merges) {
> +					printf('<a href="%s">hide merges</a>', href(-replay=>1, 'extra_options'=>('--no-merges', @extra_options)));
> +				} else {
> +					my @href_extra = grep(!/^--no-merges$/, @extra_options);
> +					printf('<a href="%s">show merges</a>', href(-replay=>1, 'extra_options'=>@href_extra));
> +				}
> +				print "</span>";
> +			}
>  		}
>  		print "\n";
>  	}

-- Etienne Vallette d'Osia

Jakub Narebski· Dec 17, 2009, 15:37 UTC · re: Giuseppe Bilotta · lore

Re: [RFC/PATCH] gitweb: link to toggle 'no merges' option

On Thu, 17 Dec 2009 10:05 +0100, Giuseppe Bilotta wrote:
> In views that support --no-merges, introduce a link that toggles the
> option.
I like this idea of introducing interface for so far hidden feature
(well, except hidden in one of feed <link ...> in page header).
 
Show 14 quoted lines
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> 
> ---
>  gitweb/gitweb.css  |   11 +++++++++++
>  gitweb/gitweb.perl |   14 ++++++++++++++
>  2 files changed, 25 insertions(+), 0 deletions(-)
> 
> This is something I've been wanting for a while. There are a number of
> things that don't 'click' with this proof of concept, and I'm coming to
> the list to hear the opinion of users and developers on how to improve
> the thing.
> 
> The patch is live at http://git.oblomov.eu/, an example affected page is
> http://git.oblomov.eu/git/shortlog

You should tell here that one must put mouse over main header (the one with 'projects / project / action' breadcrumbs) for the new link to be visible... because I was wondering where is this new link.

Show 5 quoted lines
> 
> Things that are sure to change:
> 
>  * the aesthetics and location of the toggle link (it shows on mousehover
>    in the title). 

It is not only the question where to put link, but also where to put the *code* (where the code should belong to).

At first I thought: WTF? Why the feature that deals with log-like views is put in very generic and common for all actions/views git_header_html subroutine? Especially after change that made all loglike views use common infrastructure of git_log_generic.

But then I realized that it is specific example of *generic* feature that deals with extra_options... which admittedly is currently limited to '--no-merges' only. So if it is put in git_header_html, then all views with HTML output (which does not include 'atom' and 'rss' actions, but which actions IIRC have their own handling of '--no-merges') which have support for extra_options would have ability to turn them on and off.

What you need to add (if this link is to be in git_header_html) is to create links only when $status == 200, because otherwise the link would be present also for error pages, which I think is wrong.

>    Other options I've considered are: 
>     + next to pagination (first | prev | next), either before or after
>       the existing entries

This would fit with the fact that sometimes present "patches" link is on the line with pagination links, after pagination links.

But this secondary navigation bar is about other views, and extra_options is about modifying current view, and functions more like toggles. OTOH we have such toggle for 'blame' <-> 'blame_incremental' switch in secondary navigation bar.

Also this would mean that each view type would have to handle extra_options itself, as secondary navigation bar is very much action-specific. Not that it matters now, with only single '--no-merges' option supported.

>     + on mouseover for the table section that refers to the (short)log;
>       this would make it possible to put it summary view too, for example

This would mean having link inside link, as those headers in summary view functions as link to 'shortlog' view (quite useful I think), and to the project summary in the 'shortlog' view itself (I'm not sure how useful that is). We already have problems with ref markers being links inside links and having broken layout in some strict XHTML conformance browsers.

In short: I am not sure what would be the best solution. Nevertheless I think that link should be more visible, and perhaps more toggle-like.

Show 5 quoted lines
>  * if you toggle merge view when not on the first page, the reference
>    (first) commit in the view is likely to change drastically, which
>    causes confusion. I have not found a satisfactory solution for this,
>    since the obvious way to 'lock' the view (start paginating from the
>    current top commit) prevents prev/next navigation

Alternate solution would be to clean page (start from 0th page) when changing to '--no-merges'.

You would probably need something like 'skip' option, with number of commits, not number of pages to skip, and/or 'skip_to' which takes commit-id. But i have not thought about this much...

Show 18 quoted lines
> 
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index 50067f2..0da6ef0 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -572,3 +572,14 @@ span.match {
>  div.binary {
>  	font-style: italic;
>  }
> +
> +span.merge_toggle a {
> +	font-size: 66%;
> +	color: white !important;
> +	font-weight: normal;
> +	vertical-align: top;
> +	text-decoration:none;
> +	visibility: hidden;
> +}
I think it should be more visible.
Otherwise only people "in the know" would be able to use this.
> +
> +*:hover > span.merge_toggle a { visibility:visible }

I'd rather not have this rule to have different style, i.e. not all in single line. Unless it is for RFC only...

Show 11 quoted lines
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 7e477af..a63f419 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3118,11 +3118,15 @@ sub git_header_html {
>  	my $status = shift || "200 OK";
>  	my $expires = shift;
>  
> +	my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
> +	my $has_merges = !grep(/^--no-merges$/, @extra_options);
> +
Wouldn't it be better to use straight
 +	my $no_merges = grep(/^--no-merges$/, @extra_options);

Because $has_merges is true also for example for 'tree' view... which absolutely doesn't make any sense whatsoever.

In more generic solution (which could be perhaps put in a separate commit) it could be:

  +	my %extra_options = map { $_ => 0 } keys %$allowed_options;
  +	$extra_options{$_} = 1 foreach @extra_options;

which means that %extra_options is hash which keys are allowed options, and which has true value for allowed option which is actually used.

Or something like that, if above is to cryptic.
Show 6 quoted lines
>  	my $title = "$site_name";
>  	if (defined $project) {
>  		$title .= " - " . to_utf8($project);
>  		if (defined $action) {
>  			$title .= "/$action";
> +			$title .= " (no merges)" unless $has_merges;
Wouldn't it be better to use
  +			$title .= " (no merges)" if $no_merges;
More straightforward, and without misleading $has_merges.
Show 11 quoted lines
>  			if (defined $file_name) {
>  				$title .= " - " . esc_path($file_name);
>  				if ($action eq "tree" && $file_name !~ m|/$|) {
> @@ -3235,6 +3239,16 @@ EOF
>  		print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
>  		if (defined $action) {
>  			print " / $action";
> +			if ($can_have_merges) {
> +				print " <span class='merge_toggle'>";
> +				if ($has_merges) {
> +					printf('<a href="%s">hide merges</a>', href(-replay=>1, 'extra_options'=>('--no-merges', @extra_options)));
It would be more symmetric to use:
  +					my @href_extra = ('--no-merges', @extra_options);
  +					printf('<a href="%s">hide merges</a>', href(-replay=>1, 'extra_options'=>@href_extra));
> +				} else {
> +					my @href_extra = grep(!/^--no-merges$/, @extra_options);
> +					printf('<a href="%s">show merges</a>', href(-replay=>1, 'extra_options'=>@href_extra));
> +				}
and then this conditional could be simplified a bit.
Show 9 quoted lines
> +				print "</span>";
> +			}
>  		}
>  		print "\n";
>  	}
> -- 
> 1.6.3.rc1.192.gdbfcb
> 
> 
-- 
Jakub Narebski
Poland
Giuseppe Bilotta· Dec 17, 2009, 20:41 UTC · re: Jakub Narebski · lore

Re: [RFC/PATCH] gitweb: link to toggle 'no merges' option

2009/12/17 Jakub Narebski <jnareb@gmail.com>:
Show 12 quoted lines
> On Thu, 17 Dec 2009 10:05 +0100, Giuseppe Bilotta wrote:
>> This is something I've been wanting for a while. There are a number of
>> things that don't 'click' with this proof of concept, and I'm coming to
>> the list to hear the opinion of users and developers on how to improve
>> the thing.
>>
>> The patch is live at http://git.oblomov.eu/, an example affected page is
>> http://git.oblomov.eu/git/shortlog
>
> You should tell here that one must put mouse over main header (the one
> with 'projects / project / action' breadcrumbs) for the new link to be
> visible... because I was wondering where is this new link.

I mentioned it right below, but I do realize that people might have gone looking for it before reading further down ;-)

Show 20 quoted lines
>> Things that are sure to change:
>>
>>  * the aesthetics and location of the toggle link (it shows on mousehover
>>    in the title).
>
> It is not only the question where to put link, but also where to put
> the *code* (where the code should belong to).
>
> At first I thought: WTF? Why the feature that deals with log-like views
> is put in very generic and common for all actions/views git_header_html
> subroutine?  Especially after change that made all loglike views use
> common infrastructure of git_log_generic.
>
> But then I realized that it is specific example of *generic* feature
> that deals with extra_options... which admittedly is currently limited
> to '--no-merges' only.  So if it is put in git_header_html, then all
> views with HTML output (which does not include 'atom' and 'rss' actions,
> but which actions IIRC have their own handling of '--no-merges')
> which have support for extra_options would have ability to turn them
> on and off.

Exactly. Although the code as it is now is not really flexible enough to handle other cases. I see further down a couple of your ideas would make this kind of thing more extensible.

> What you need to add (if this link is to be in git_header_html) is
> to create links only when $status == 200, because otherwise the link
> would be present also for error pages, which I think is wrong.
Good point. That's an easy fix too 8-)
Show 11 quoted lines
>>    Other options I've considered are:
>>     + next to pagination (first | prev | next), either before or after
>>       the existing entries
>
> This would fit with the fact that sometimes present "patches" link is on
> the line with pagination links, after pagination links.
>
> But this secondary navigation bar is about other views, and extra_options
> is about modifying current view, and functions more like toggles.  OTOH
> we have such toggle for 'blame' <-> 'blame_incremental' switch in
> secondary navigation bar.

Well, at least for this particular option the toggle is closer in concept to pagination (which also modifies the 'current' view, in a way).

> Also this would mean that each view type would have to handle extra_options
> itself, as secondary navigation bar is very much action-specific.  Not
> that it matters now, with only single '--no-merges' option supported.

Even with more options, I have half an idea on how to refactor this handling in a way that should make it easy for views to handle the extra options.

Show 8 quoted lines
>>     + on mouseover for the table section that refers to the (short)log;
>>       this would make it possible to put it summary view too, for example
>
> This would mean having link inside link, as those headers in summary view
> functions as link to 'shortlog' view (quite useful I think), and to the
> project summary in the 'shortlog' view itself (I'm not sure how useful
> that is).  We already have problems with ref markers being links inside
> links and having broken layout in some strict XHTML conformance browsers.

(I still think that prohibiting link-in-link is idiotic, but this is not the place where this should be discussed)

> In short: I am not sure what would be the best solution.  Nevertheless
> I think that link should be more visible, and perhaps more toggle-like.
I'll see if I can cook something up.
Show 12 quoted lines
>>  * if you toggle merge view when not on the first page, the reference
>>    (first) commit in the view is likely to change drastically, which
>>    causes confusion. I have not found a satisfactory solution for this,
>>    since the obvious way to 'lock' the view (start paginating from the
>>    current top commit) prevents prev/next navigation
>
> Alternate solution would be to clean page (start from 0th page) when
> changing to '--no-merges'.
>
> You would probably need something like 'skip' option, with number of
> commits, not number of pages to skip, and/or 'skip_to' which takes
> commit-id.  But i have not thought about this much...

IIRC the log code uses pagination the way it is now because that reflects the git log works. This would make a different approach more time consuming on the script part.

Show 5 quoted lines
>> +
>> +*:hover > span.merge_toggle a { visibility:visible }
>
> I'd rather not have this rule to have different style, i.e. not all
> in single line.  Unless it is for RFC only...
I can make it more like the others.
Show 10 quoted lines
>> +     my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
>> +     my $has_merges = !grep(/^--no-merges$/, @extra_options);
>> +
>
> Wouldn't it be better to use straight
>
>  +      my $no_merges = grep(/^--no-merges$/, @extra_options);
>
> Because $has_merges is true also for example for 'tree' view... which
> absolutely doesn't make any sense whatsoever.

The reason why I have two vars is that one checks if we care about the option, and the other is to see if it's enabled or not. We don't want the 'show merges' toggle to appear in view which don't handle the --no-merge option.

Show 8 quoted lines
> In more generic solution (which could be perhaps put in a separate commit)
> it could be:
>
>  +     my %extra_options = map { $_ => 0 } keys %$allowed_options;
>  +     $extra_options{$_} = 1 foreach @extra_options;
>
> which means that %extra_options is hash which keys are allowed options,
> and which has true value for allowed option which is actually used.

I like this approach. It's also easier to extend to other options, if and when we'll have them.

I'll try to roll out a new patch with a cleaner design and taking your suggestions into considerations

-- 
Giuseppe "Oblomov" Bilotta
Jakub Narebski· Dec 17, 2009, 21:14 UTC · re: Giuseppe Bilotta · lore

Re: [RFC/PATCH] gitweb: link to toggle 'no merges' option

Giuseppe Bilotta wrote:
> 2009/12/17 Jakub Narebski <jnareb@gmail.com>:
>> On Thu, 17 Dec 2009 10:05 +0100, Giuseppe Bilotta wrote:
[...]
Show 15 quoted lines
>>> +     my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
>>> +     my $has_merges = !grep(/^--no-merges$/, @extra_options);
>>> +
>>
>> Wouldn't it be better to use straight
>>
>>  +      my $no_merges = grep(/^--no-merges$/, @extra_options);
>>
>> Because $has_merges is true also for example for 'tree' view... which
>> absolutely doesn't make any sense whatsoever.
> 
> The reason why I have two vars is that one checks if we care about the
> option, and the other is to see if it's enabled or not. We don't want
> the 'show merges' toggle to appear in view which don't handle the
> --no-merge option.
Perhaps I didn't made myself clear.

What I wanted to ask is to switch $has_merges to $no_merges, not to remove $can_have_merges. Its a question of semantics of $has_merges, which do not mean that action has (handles) merges.

This is of course the question of style, but I think this would make code more maintainable.

Of course if you go %extra_options hash route this issue wouldn't matter.
-- 
Jakub Narebski
Poland

← back to recent threads