Couple of more things:
1. it will help if commit messages are prefixed with the JIRA #. Like:
ATLAS-1114: Performance improvements for create/update entity
2. Once the patch is committed, please add the commit details in the JIRA.
I find copy/paste of the link sent in the commit email helpful. Like:
Committed to master:
http://git-wip-us.apache.org/repos/asf/incubator-atlas/commit/89f70609
Thanks,
Madhan
On 1/27/17, 9:31 AM, "Madhan Neethiraj" <[email protected] on behalf
of [email protected]> wrote:
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
better 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
