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

Re: GitWeb: Adding fork visualization based on objects/info/alternates

From
Petr Baudis <pasky@suse.cz>
Date
May 28, 2007, 13:00 UTC
Message-ID
<20070528130038.GR4489@pasky.or.cz>
In-Reply-To
<46587CE5.1030501@trolltech.com>
  Hi,
On Sat, May 26, 2007 at 08:31:01PM CEST, Marius Storm-Olsen wrote:
Show 20 quoted lines
> In an effort to tidy up the project list, and given that the
> current fork support in GitWeb doesn't exactly fit my
> structure (where forks are in subdirs of parent repo, and has
> to be first level down; alas no seek unlike when not showing
> forks), I set out to add fork support based on
>     objects/info/alternates
> of each repo. The result can be seen here:
>     http://chaos.troll.no/~marius/git/forks_collapsed.png
>     http://chaos.troll.no/~marius/git/forks_expanded.png
> 
> I doubt you'd want it in the mainline, as you can't turn the
> feature off; it's just like another column which you can sort
> by. If you do not sort by the 'fork' column, the forks will
> still be colored with the first level color, but not ordered
> under it's parent repo.
> 
> Just wanted to feed back what I did so others can get
> inspiration, tweak it, and add it to their own gitwebs.
> 
> It cleans up the project list real nicely though.
  I think this patch is quite an interesting idea, and I kind of like
the possibility to show forks in the summary project list, if it's
optional (I actually don't think if I would enable this say at
repo.or.cz - some projects have quite a lot of forks and it would
clutter it up a lot e.g. for text-mode browsers that don't grok
enough javascript). OTOH, taking fork info from alternates is more
controversial; I don't want to force the repo.or.cz forks model on
everyone but having $proj in alternates may not mean it is a fork... but
if more people think it's a reasonable heuristic, we might optionally
support it too.
  If you would be willing to split this patch to two and make both
features optional (and sign off the patch), I think at least the
forks-in-summary part might be quite a worthy addition.
Show 11 quoted lines
> @@ -1909,8 +1919,9 @@ EOF
>  		print qq(<link rel="shortcut icon" href="$favicon" type="image/png"/>\n);
>  	}
> 
> +	print "<script src=\"gitweb_scripts.js\" type=\"text/javascript\"></script>\n";
>  	print "</head>\n" .
> -	      "<body>\n";
> +	      "<body onload=\"collapseAllRows();\">\n";
> 
>  	if (-f $site_header) {
>  		open (my $fd, $site_header);

Would it be more reasonable to just set the style for these rows by default to display: none?

> --- /dev/null
> +++ b/gitweb/gitweb_scripts.js

We have other patch introducing blame.js, so maybe call this forks.js? Or do we have a strong reason to prefer a single .js file with all the lot?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett
Previous: Marius Storm-Olsen
Message 2 of 2 in “GitWeb: Adding fork visualization based on objects/info/alternates”
  1. Marius Storm-OlsenMay 26, 2007
  2. Petr BaudisMay 28, 2007

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.