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

Re: Incorporating gitweb-xmms2 features in trunk gitweb

From
Jakub Narebski <jnareb@gmail.com>
Date
Jun 30, 2006, 09:59 UTC
Message-ID
<200606301159.38431.jnareb@gmail.com>
In-Reply-To
<449EF8A9.3080301@xmms.org>
Sham Chukoury <eleusis[@]xmms[.]org> wrote:
Show 10 quoted lines
> Jakub Narebski wrote:
>> Now (from git 1.4.0) that gitweb is incorporated in main git.git 
>> repository, and patches to it are accepted by Junio on git mailing 
>> list, I have taken to adding new features to gitweb.
>> 
>> I've planned on adding gitweb-xmms2 features (using separate topic 
>> branches for each feature, like snapshots, hightlighting, committags).
>> Perhaps we could coordinate efforts?
> 
> Coordination sounds great. What do you have in mind? :)
Actually it seems that I wouldn't have much time (at least in near future)
for work on gitweb. The main thing stopping me is that gitweb needs
refactoring before adding (or re-adding) new features, as it is written
partially at least in copy'n'paste style, AND waiting for Git.pm Perly git
interface (I'd like to have perl-only Git.pm and use it in gitweb, but 
pasky who develops it uses XS for speed).
 
An example of such refactoring is your separation of navbar generation
code. Similar work was done by Sven Verdoolaege when introducing in-gitweb
snapshot code in
  "gitweb and tar snapshots"
  http://marc.theaimsgroup.com/?l=git&m=111909432415478&w=2
  http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary
  http://www.liacs.nl/~sverdool/gitweb.git#master
In my opinion your navbar code is too tied up with current navbar, while
sverdool is a little too perl-hackerish (e.g. there is only one instance,
i.e. root commit, where "top" part of navbar is not default, i.e. it
lacks "commitdiff" (to parent)).
Show 7 quoted lines
>> For now from gitweb-xmms2.git I have only cherry-picked "Make CSS 
>> readable" commit 561262030d58a6325f500b36d836dbe02a5abc68.
> 
> Bear in mind that, since 'forking' (for lack of a better word) from v264, I 
> haven't merged any changes from the 'official' gitweb tree.. Last time I 
> checked, there's at least one changeset I reimplemented differently (perhaps 
> wrongly). I need to go back and see what needs to be fixed properly..

gitweb-xmms2 merged quite cleanly with 1.4.0. It was later changes in next (among others adding optional "blame" view for blobs, using old navbar generation) that makes automatic merge fail.

> Going back to the point on coordination - I currently track bugs and feature 
> requests for gitweb-xmms2 using the xmms2 bug tracker at 
> http://bugs.xmms2.xmms.se (You'll need to select the 'Misc - gitweb' project 
> from the dropdown at the top right of the page to see the relevant reports)
Check my two threads on gitweb wishlist features, and plans on refactoring
on git mailing list:
  "[RFC] gitweb wishlist and TODO list"
  Message-ID: <e79921$u0e$1@sea.gmane.org>
  http://permalink.gmane.org/gmane.comp.version-control.git/22213
  http://marc.theaimsgroup.com/?l=git&m=115082279425118&w=2
and
  "gitweb refactoring"
  Message-ID: <e7ed1r$9ve$1@sea.gmane.org>
  http://permalink.gmane.org/gmane.comp.version-control.git/22345
  http://marc.theaimsgroup.com/?l=git&m=115099031220954&w=2

P.S. Now that gitweb is included in git.git (from git version 1.4.0), you should have easier to have your patches accepted into gitweb trunk.

-- 
Jakub Narebski
ShadeHawk on #git
Message 1 of 1 in “Re: Incorporating gitweb-xmms2 features in trunk gitweb”
  1. Jakub NarebskiJun 30, 2006

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.