Re: gitweb and remote branches

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.

On

  http://oblomov.dnsalias.org/git?p=git.git;a=heads

I don't see any difference between formatting of remote heads and local
branches.
 

quoted

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

 
[...]

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.

You can also make a git fork at http://repo.or.cz

-- 
Jakub Narebski
Poland