From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:31
On Tue, 28 August 2007, Giuseppe Bilotta wrote:
On 8/28/07, Giuseppe Bilotta [off-list ref] wrote:
quoted
I've given a better look at the code and I think I can whip up a patch
to implement the feature. I have no idea about how to create a new
option in gitweb though, so I'll have to leave it that to someone
else.
Ok, this is hopefully the last time I reply to myself. I'm inlining
the quick'n'dirty patch I've whipped up, hoping that gmail doesn't
destroy it too much..
For quick'n'dirty solution this might be enough. For proper patch to
be accepted I don't think so.
First, in the idea to show also remote branches (from refs/remotes),
I wanted to separate heads list from remotes list in the 'summary'
view, and add 'remotes' view or modify 'heads' view to accept some
parameter specyfying kind of refs.
Second, what was stopping me from implementing that was an idea to
separate remote branches into categories (like gitwbe-xmms2 categories
of projects) defined by the remote it belongs to. And this is not so
easy if we want to respect old .git/branches/ and .git/remotes/ remote
config in addition to new config based remote config.
It is better to use git to manage source and to generate patches
(use git-format-patch, check Documentation/SubmittingPatches),
and use gitweb/gitweb.perl and not installed version.
[...]
I don't understand this double span. First, you can set multiple
classes for HTML element by separating them by space, e.g.
"<span class=\"refs\ $ref{'class'}\">"
And you could have given appropriate class to <td> or <a> element
--
Jakub Narebski
Poland
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:43:31
On 8/30/07, Jakub Narebski [off-list ref] wrote:
For quick'n'dirty solution this might be enough. For proper patch to
be accepted I don't think so.
That's fine, it wasn't meant to be :)
First, in the idea to show also remote branches (from refs/remotes),
I wanted to separate heads list from remotes list in the 'summary'
view, and add 'remotes' view or modify 'heads' view to accept some
parameter specyfying kind of refs.
What I had in mind was a way to modify 'heads' view with a boolean
option that enable/disabled remotes view. For their visualizations, I
had in mind a split 'heads' secion, with the lhs being as it is now,
and the rhs having the remotes.
However, I wasn't sure if such a view would have been appreciated, so
I went for the merged view and used the spans to make the heads appear
as they do in the shortlog, as a clear way to mark which ones were
local and which ones were remote.
Second, what was stopping me from implementing that was an idea to
separate remote branches into categories (like gitwbe-xmms2 categories
of projects) defined by the remote it belongs to. And this is not so
easy if we want to respect old .git/branches/ and .git/remotes/ remote
config in addition to new config based remote config.
I don't know what gitweb-xmms2 does, but I think I understand what you
mean, and I like the idea. However, it's even harder if you consider
that even the latest git-svn plops all the svn-converted refs straight
into refs/remotes and not in a subdir such as refs/remotes/svn.
OTOH, we have to start from somewhere so we can build the feature step by step.
It is better to use git to manage source and to generate patches
(use git-format-patch, check Documentation/SubmittingPatches),
and use gitweb/gitweb.perl and not installed version.
Oh, I know, this was just a very quick hack on the thing installed by
my Debian distribution. I've since checkoued out the git.git
repository and I'll be working on that now.
I don't understand this double span. First, you can set multiple
classes for HTML element by separating them by space, e.g.
"<span class=\"refs\ $ref{'class'}\">"
And you could have given appropriate class to <td> or <a> element
Actually, that was just a quick hack to make the heads appear in the
heads list in the same way as they appear in the shortlog, to
differentiate between them. And that requires the double span ;)
Of course, I'd rather hack the CSS now that I've got the git repository.
I'll be working on it here
http://oblomov.dnsalias.org/git?p=git.git;a=shortlog;h=gitweb-allheads
and keep you posted on my progress.
--
Giuseppe "Oblomov" Bilotta
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:31
On Thu, 30 August 2007, Giuseppe Bilotta wrote:
On 8/30/07, Jakub Narebski [off-list ref] wrote:
quoted
First, in the idea to show also remote branches (from refs/remotes),
I wanted to separate heads list from remotes list in the 'summary'
view, and add 'remotes' view or modify 'heads' view to accept some
parameter specyfying kind of refs.
What I had in mind was a way to modify 'heads' view with a boolean
option that enable/disabled remotes view.
That is a good idea. We can for example use extra_options ('opt')
parameter to pass 'refs/remotes' etc. to 'heads' view. Or we can
use some new CGI parameter. Or just make it configurable in gitweb
configuration, with per repository override, i.e. make it into
%feature.
For their visualizations, I
had in mind a split 'heads' secion, with the lhs being as it is now,
and the rhs having the remotes.
Care to provide some ascii-art mockup?
What I had in mind was for 'summary' view (*bold*, _underline_):
[heads]
27 min ago _gitweb-allheads_ shortlog | log | tree
24 hours ago master shortlog | log | tree
[remotes]
*origin*
24 hours ago man shortlog | log | tree
24 hours ago html shortlog | log | tree
24 hours ago next shortlog | log | tree
24 hours ago pu shortlog | log | tree
24 hours ago _master_ shortlog | log | tree
2 weeks ago maint shortlog | log | tree
2 weeks ago todo shortlog | log | tree
and similarly for 'remotes' view (or 'heads').
Note that we remove remote name from remote branch name, although
we can leave it as is (i.e. origin/man vs. man), and that we filter
out HEAD if it points to existing branch, marking one of the branches
as current instead.
That reminds me that gitweb has no support for detached HEAD as of yet,
although I don't think we want to encourage detached HEAD in public
repo.
However, I wasn't sure if such a view would have been appreciated, so
I went for the merged view and used the spans to make the heads appear
as they do in the shortlog, as a clear way to mark which ones were
local and which ones were remote.
Second, what was stopping me from implementing that was an idea to
separate remote branches into categories (like gitwbe-xmms2
categories of projects) defined by the remote it belongs to. And
this is not so easy if we want to respect old .git/branches/
and .git/remotes/ remote config in addition to new config based
remote config.
I don't know what gitweb-xmms2 does, but I think I understand what you
mean, and I like the idea.
See my mockup and 'summary' view of gitweb-xmms2 installation:
http://git.xmms.se/
However, it's even harder if you consider
that even the latest git-svn plops all the svn-converted refs straight
into refs/remotes and not in a subdir such as refs/remotes/svn.
Or refs/svn. I think that dumping remotes directly into refs/remotes
and not to refs/remotes/<remote> is a bug (also in git-svn).
OTOH, we have to start from somewhere so we can build the feature
step by step.
We can start without separating into remotes category-like, i.e.
with the following mockup:
[remotes]
24 hours ago origin/man shortlog | log | tree
24 hours ago origin/html shortlog | log | tree
24 hours ago origin/next shortlog | log | tree
24 hours ago origin/pu shortlog | log | tree
24 hours ago _origin/master_ shortlog | log | tree
2 weeks ago origin/maint shortlog | log | tree
2 weeks ago origin/todo shortlog | log | tree
[...]
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:43:31
On 8/30/07, Jakub Narebski [off-list ref] wrote:
On Thu, 30 August 2007, Giuseppe Bilotta wrote:
quoted
What I had in mind was a way to modify 'heads' view with a boolean
option that enable/disabled remotes view.
That is a good idea. We can for example use extra_options ('opt')
parameter to pass 'refs/remotes' etc. to 'heads' view. Or we can
use some new CGI parameter. Or just make it configurable in gitweb
configuration, with per repository override, i.e. make it into
%feature.
For the time being I've made it into a project-overridable %feature.
(It was easier to set up than I though.) I do like the idea of having
it also as an additional CGI parameter.
quoted
For their visualizations, I
had in mind a split 'heads' secion, with the lhs being as it is now,
and the rhs having the remotes.
Care to provide some ascii-art mockup?
(monospace view)
[heads] | [remotes]
date headname links | date headname links
date headname links | date headname links
or a variation thereof. However, I have a 1600x1200 screen so not
everybody might be confortable with such a view.
What I had in mind was for 'summary' view (*bold*, _underline_):
[heads]
27 min ago _gitweb-allheads_ shortlog | log | tree
24 hours ago master shortlog | log | tree
[remotes]
*origin*
24 hours ago man shortlog | log | tree
24 hours ago html shortlog | log | tree
24 hours ago next shortlog | log | tree
24 hours ago pu shortlog | log | tree
24 hours ago _master_ shortlog | log | tree
2 weeks ago maint shortlog | log | tree
2 weeks ago todo shortlog | log | tree
and similarly for 'remotes' view (or 'heads').
I think I like yours better. I had just implemented split
remotes/heads list in summary view, so I'll keep working towards your
idea.
Note that we remove remote name from remote branch name, although
we can leave it as is (i.e. origin/man vs. man),
Yes, I'll work on this next.
and that we filter
out HEAD if it points to existing branch, marking one of the branches
as current instead.
I don't know if I'll be able to implement this, but I'll try :)
quoted
However, I wasn't sure if such a view would have been appreciated, so
I went for the merged view and used the spans to make the heads appear
as they do in the shortlog, as a clear way to mark which ones were
local and which ones were remote.
Indeed, I removed the thing when I started working on the repo.
quoted
However, it's even harder if you consider
that even the latest git-svn plops all the svn-converted refs straight
into refs/remotes and not in a subdir such as refs/remotes/svn.
Or refs/svn. I think that dumping remotes directly into refs/remotes
and not to refs/remotes/<remote> is a bug (also in git-svn).
I think so too. I'll report it as a bug to the git-svn developers.
Oh, interesting. Just clicking on the 'fork' link in
http://repo.or.cz/w/git/gitweb.git and filling up the form?
I'll set that up as a mirror shortly.
--
Giuseppe "Oblomov" Bilotta