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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html