Re: Some help on gitweb project.

[Jakub Narebski <jnareb@gmail.com>]

On Sun, 13 May 2012, jaseem abid wrote:

> Dear all,
> 
> I have been working on gitweb for a couple of days as part of a
> rejected GSoC proposal. I would love to get some help on this and if
> somebody can, that would be thankful.
> 
> 1. How is code tested after some change? I am not talking about unit
> testing but about making sure that application is doing what it is
> actually intended to do. Do you have to re - install git/gitweb with
> every version of code you commit and make sure that it works well and
> as expected? Or, is there some other way? Sorry but I am a newbie when
> it comes to FOSS contribution and as well working on a project of this
> magnitude.
> 
> As far as I understand, gitweb by default is looking for files from
> `/usr/share/gitweb/` (I work on Debian Sid if that helps). If I edit
> the perl or some JavaScript code, how should I test it? *Install* my
> version from source as mentioned in "gitweb/INSTALL" ?

One possibility is to install gitweb with "make -C gitweb install"
or "make install-gitweb".

The other is to set up config file in such way that gitweb.perl
would work with it; see the config file for t950x tests, the one
inside t/gitweb-lib.sh.

Though in latter case you can miss some errors...
 
> 2. How I should be committing ?
> 
> Personally I commit on *very* small changes, so that I can easily get
> back to any point and do bisects well and good, but I see the patches
> in the mailing list to be polished and fine tuned. Commit somehow
> comfortably and then polish it in another branch with rebase and
> squashes and then submit it for comments on mailing list?
> 
> Refer please: 
http://sethrobertson.github.com/GitBestPractices/#sausage

First, I alway use [interactive] rebase or equivalen (like patch 
management interfaces: StGit, Guilt, TopGit) to clean up patches
prior to submission.

Second, please do not think that the first attemt must be perfect.
The usual workflow is that one send RFC patches, people comment,
corrected version is sent, etc., etc... until the patch series is
polished to first get out RFC status then (if possible) get accepted.

> 3. How will I submit a commit like "Adding jQuery library"? Mail a
> whole minimized JavaScript library to the mailing list? How can
> somebody crosscheck the contents of a minimized JavaScript library ?
> 
> Earlier Jakub mentioned about adding CDN support for the library,
> which I think is a very good feature. How should I do this? Add an
> extra config/build variable to select b/w local and CDN version ?

I think that it would be simpler to start with CDN support in the form
of (for example) $jquery_url gitweb config variable and JQUERY_LINK
build-time configuration variable.

In the case the Internet access is lacking or intermittent, $jquery_url
might be to static file not to CDN.

And of course if ultimately we decide that we need to support providing 
out own work-tested version of gitweb, it can be done iff $jquery_url
is undefined or empty string -- fallback to in-repo copy, perhaps 
outdated but tested that it works.

> 4. At what stage is code to be submitted? After the full project is
> done or in a modular manner? Can I ask for some review and help from
> if I push the code to github and share the link, or do I have to mail
> that also? I don't want to repeat this :
> https://github.com/torvalds/linux/pull/17

Git development is based on git mailing list, not GitHub web interface.
In early stages you can send pull requests by private email (to mentors)
or to git mailing list; in final stages you better send patch series,
unless series is long and with large patches -- then pull request via 
email would be suitable.
 
> 5. What should be my base commit/branch for starting the work ?

Add include for jQuery (Makefile, gitweb.cgi, gitweb.txt) and check it.

-- 
Jakub Narebski
Poland