Hi Andreas, On Wed, Mar 23, 2011 at 8:14 PM, Andreas Schueller <aschuel...@bio.puc.cl> wrote: > I'd be happy to provide some/all of the patches. But I'd like to enquire > about the correct procedure, especially since I've never used Git before.
Are you happy with things on a command line? First, make sure git knows who you are: > git config --global user.name "Firstname Lastname" > git config --global user.email "your_em...@youremail.com" This is used by 'git commit'. Now, set up a local repository (aka fork, clone, and branch): > git clone https://eg...@github.com/cdk/cdk.git Then make a local branch for the upstream cdk-1.4.x branch: > git checkout -b cdk-1.4.x origin/cdk-1.4.x Now, you can best do all your work in branches, so that your local cdk-1.4.x never has patches that are not in the upstream repository (by default called 'origin'). So, create a branch of the cdk-1.4.x branch: > git checkout -b 1-14x-myVeryFirstPatch cdk-1.4.x The actual branch name doesn't matter... I use a pattern over IncrementedValue-originBranchCodeID-someShortDescriptiveLabel... so: 1-14x-myVeryFirstPatch. The second patch, I would develop in a branch, e.g. called 2-14x-mySecondAndCoolerPatch. The branchCodeID I do to make it clear for myself from with main branch I branched: 14x for cdk-1.4.x and m for master. OK, now it is time to make a hack. Check also this post: http://chem-bla-ics.blogspot.com/2011/03/why-i-like-linux-its-fast-or-quick-typo.html I can recommend to start with a really simple patch... you to get familiar with the commands... so a simply spell check error is what I normally advice... > nano src/main/org/openscience/cdk/Atom.java (or so) Make sure to check what git says you changed: > git status > git diff The first shows the changed files, and the second what in fact changed. The next step is different from CVS and SVN: you need to stage changes as to be commited. Say, you changed Atom.java, you can do: > git add src/main/org/openscience/cdk/Atom.java > git status The second to confirm that Atom.java is now 'staged'. To stage all changed files that are already part of your local git repository, you can also simply do: > git add -u > git status (Do that git status a lot, so that you 'see' what is happening.) Next, once you are happy with the 'staged' changes, you can make the commit: > git commit -m "Fixed a spelling error" Make sure to give a good descriptive message. Nothing like "Fixed bug", but descriptor what bug you fixed, and preferably also how (for spelling errors the above is fine). So something like: "Fixed element symbols for PDB atom types" Here it is clear what was fixed and how. Or: "Renamed Strand to Chain to reflect PDB common naming" describing first how you fixed it, and then what. When that is done, you can check your patch with the following two commands: > git log > git show The last shows the more recent patch. And when you are happy with that too (if not, join #cdk at irc.freenode.net, and I'll talk you through some git wizardy :), then you can convert this patch into a text file you can 'file' (see later): > git format-patch -1 Now, if you have made two patches, you'd do 'git format-patch -2'... if you made many patches, you can also create patches from a certain commit. Note that branches are nothing more than 'aliases' for commit hashes (those long 20 char hexadec codes). But, considering you did the above, and branched from 'cdk-1.4.x', then you can also create patches for your branch with 'git format-patch cdk-1.4.x'. This will create files that look like 0001-SomeCommitMessage.patch. These are ASCII files, and suitable for emailing etc. Now, you file this report. This you can do in various ways: send them as attachments to the cdk-patches@ mailing list. Most people, however, create an entry in the Patch tracker at: http://sourceforge.net/tracker/?group_id=20024&atid=320024 You need a SourceForge account for that (because we were getting too much spam) and be logged in. In both cases, indicate for which branch the patch is aimed (cdk-1.4.x or master, the first in this example). The patch will then be reviewed by others. Those others will basically do something like this: > git am -3 --ignore-whitespace 0001-SomeCommitMessage.patch > git show > ant clean dist-all test-dist-all > git commit --amend --signoff > git format-patch -1 (Assuming all individual steps went fine, and the patch is OK :) And upload the 'signed off' patch back into the tracker, to be applied and committed to the main repository by Rajarshi or me. Is that useful to get you started? Egon -- Dr E.L. Willighagen Postdoctoral Researcher Institutet för miljömedicin Karolinska Institutet Homepage: http://egonw.github.com/ LinkedIn: http://se.linkedin.com/in/egonw Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Cdk-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
