David, Few patches attached in JIRAs miss details like author, subject. And such patches make the committer’s job a little harder - as these details need to be filled in by the committer. There is always a chance of mistake here, especially if a large number of patches are being handled by the person. It will help if these details are entered by the author of the patch.
In addition, patches generated by “git format-patch” can be applied with “git am” and easily reverted with “git reset”. Often committers need to do reverts if the patch needs fixes by the author. With other format, revert takes additional steps - especially if the patch adds new files (“git --checkout .”does not remove the new files). Perhaps there are better ways to deal with this, but we have been using this approach in Apache Ranger and it has been very helpful. Let me know if you find any difficulties with this or have suggestions for a b etter approach. Thanks, Madhan On 1/27/17, 4:15 AM, "David Radley" <[email protected]> wrote: Hi Madhan, I have been using the rbt command to send code for review, I then download the patch using the rbt tool and attach that patch to the Jira; this seemed natural as the patch code is then the same as what is reviewed in the rbt tool. I am interested how this approach might be causing issues, I suggest it would be helpful for people who are new to Git (like me) if you could mention your thinking as to why your approach is preferable. I guess, when you come to update the patch, if the latest code has affected the files in the first patch, you will need to pull, then merge prior to the rebase. Is this obvious or do you want to spell this out? It seems to me if we are going to document recommended ways of using git commands, then we need to consider this scenario, many thanks, David. From: Madhan Neethiraj <[email protected]> To: "[email protected]" <[email protected]> Date: 27/01/2017 00:57 Subject: Guidelines to create patch for review Atlas team, I would request you to consider creating patches with the following steps. It will save reviewers and committers considerable time in dealing with patch apply/revert, adding the commit message and author info etc. Initial patch for a review: 1. git add <files to be included in the patch> 2. git commit -m “ATLAS-1234: commit message that will go into git” 3. git format-patch origin/master 4. rename the file to: ATLAS-1234.patch 5. Attach ATLAS-1234.patch to the JIRA and create a review in review board. Subsequent updates for the same review: 1. git add <files to be updated in the patch> 2. git commit -m “updated” 3. merge this commit with earlier one: - git rebase -i - a file should open up in your text editor. Change the first word in the second line - from “pick” to “s” - another file should open up in your text editor. Remove the lines for the second commit message. 4. git format-patch origin/master 5. rename the file to: ATLAS-1234-1.patch 6. Attach ATLAS-1234.patch to the JIRA and create a review in review board. Thanks, Madhan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
