Some help on gitweb project.

Dear all,

CC : Andrew Sayers, Jakub Narębski

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" ?

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

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 ?

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

5. What should be my base commit/branch for starting the work ?

V/r,

Jaseem Abid http://jaseemabid.github.com

On Sun, May 13, 2012 at 11:11 PM, jaseem abid <jaseemabid@gmail.com> wrote:

Adding a bit more to the last mail. In the specific case of gitweb, I can sym link files from `/usr/share/giweb` or any installation folder to the working directory for testing. Then all I have to do is to rebuild the files and forget about moving the files to right place. Is it ok to develop this way? I am looking for some good practices here on this.

-- Jaseem Abid http://jaseemabid.github.com

Jaseem and I discussed this in IRC. You can see the log here: http://colabti.org/irclogger/irclogger_log/git-devel?date=2012-05-13

Or see the (roughly) equivalent text below.

On 13/05/12 18:41, jaseem abid wrote:

Your later suggestion of symlinking /usr/share/giweb seems like it should work. Alternatively, you could point Apache straight at your repo. I don't think this is a situation where subtle issues creep up on you - if it looks like it works, it probably does.

Private commits are your own business. When it comes time to push work out for public consumption, I like to think of it as telling a story - start at the beginning and concisely explain what happened.

Probably best not to include jQuery in git itself - aside from anything else, it will be a big hassle to maintain. Better to have a variable like "jquery_url" with a default like "https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js" (i.e. Google's CDN). That avoids the need to include jQuery in git, and lets people e.g. link different gitweb instances to a single library on their local network.

I expect it will become obvious when to submit code as your work continues. For example, if you get into TDD and write a bunch of unit tests before anything else, you might want to send them in their own patch series. I guess it's more likely you'll end up with one big patch series though.

Speaking for myself, I'm happy to look at code either here or on github.

Documentation/SubmittingPatches says:

 - A new feature should be based on 'master' in general.

	- Andrew

On Sun, 13 May 2012, jaseem abid wrote:

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...
 

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.

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.

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.
 

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