On Feb 7, 2011, at 11:16 AM, Max Horn wrote: > * Even better, non-devs can also make forks, but instead of directly > merging their changes, they can file a "pull request", i.e. they can > ask the Fink team to integrate their new package or package updates. > Consider this as an advanced alternative to the Package submission > tracker. Only that it is possible to accept new packages/fixes with > a single button click from inside the browser. And if the submission > is lacking, you can provide feedback and request changes, and even > comment on the submitted code -- even making line annotations. This > really simplifies patch submissions for everybody involved (once you > learned the minimal git you need to submit stuff this way, at least).
The GitHub comments and line annotations seem like they would speed up the discussion between new packagers and the committers. Having to download and apply each patch is slightly tedious and error-prone, but this makes it easier for the submitters to run "git commit -a", see if they left any files out, and push to their fork. Besides the usual local Git visualization tools (gitk and GitX), GitHub has their own web-based system to show how forks relate to each other. Click "Network" on any GitHub project, and it will show commits versus time and branch. I have a "lite" version of the Fink tree in Git here - basically, I check in just the info files I maintain, and have Git ignore the other info files, plus the CVS metadata. If I venture into the package submission tracker, switching branches to try a new package is absurdly fast. (Tracking the whole tree would be a bit slower, but still way faster than "svn switch".) It also makes it easier to merge in my changes (e.g. updating a library dependency), even if the submitter makes a few changes on top of their original submission. This is where "git rebase" comes in handy. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
