From: Petr Baudis <pasky@suse.cz>
To: Marius Storm-Olsen <marius@trolltech.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: GitWeb: Adding fork visualization based on objects/info/alternates
Date: Mon, 28 May 2007 15:00:38 +0200 [thread overview]
Message-ID: <20070528130038.GR4489@pasky.or.cz> (raw)
In-Reply-To: <46587CE5.1030501@trolltech.com>
Hi,
On Sat, May 26, 2007 at 08:31:01PM CEST, Marius Storm-Olsen wrote:
> 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.
> @@ -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
prev parent reply other threads:[~2007-05-28 13:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-26 18:31 GitWeb: Adding fork visualization based on objects/info/alternates Marius Storm-Olsen
2007-05-28 13:00 ` Petr Baudis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070528130038.GR4489@pasky.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=marius@trolltech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).