On Tue, Feb 19, 2013 at 8:27 AM, Dean Gibson AE7Q data@ae7q.net wrote:
On 2013-02-19 06:38, Dan Smith wrote:
Okay, here is my ID-51 (id51.py) new driver. Also included is an image file for same.
Could you put it into the proper patch format?
http://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess#Submitting-...
OK, I'm confoozed. I previously read that page, and I know that's the correct format for a change. Once you/me have decided that the changes I have for the ID-31 are appropriate as well, those will obviously be in patch format. However, for a new driver, the whole file is new, so I don't understand the procedure for that. For the image file, your page says:
A new file is a change to Chirp. After adding the new file, Chirp is not the same as it was before. But that's not the point here...
So, that's what I did. "hg status -mar" only shows the id31.py changes, which I'm not ready (per above) to submit yet. I included the complete id51.py file in my previous eMail so you could see the differences (via the two diffs) before I formally submitted a patch.
"hg status -mar" does nothing to attribute the changes to you, or label them with an appropriate commit message. Our goal here isn't just to add new lines of code, but to document who added them and why, so that future readers of the code can ask "what was the guy who wrote this thinking??" and have both the explanation (commit message) and name/email of the guy who wrote it. If we find that your change introduces a regression, we are also easily able to search for commit messages containing "id?1" and revert each as needed until the regression disappears.
hg diff:
For this all to work, you must use a different command, "hg qnew ..." to create your patch. You will be prompted to enter a commit message, and when you export it ("hg export tip") your name and email address will be automatically be added to the header. The commands to accomplish this are all listed here:
http://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess#Soft-commit...
When using "hg q.." commands, your changes are not permanent. You can send a work-in-progress patch (see Sending a Change), ask some questions, modify your code, then use "hg qref" to update the patch.
A little bit of record keeping is necessary for managing a large codebase, and I think you'll find the learning curve for hg mq is minimal and saves you effort in the long run.
Tom KD7LXL