I'd be happy to do this though I do need some help with the git commands to generate my patch. Any tips Dan? I'll do some searching tomorrow.
Also one more git question. The process I need to follow (that you described at the end of your email) to bring my fork up to date seems a little complex. Did I do things in the correct way? Should I have done my work in a branch? Any advice to make future pull requests painless is appreciated. Thanks. -- Adam On Fri, Jul 13, 2012 at 1:40 AM, Mark Struberg <[email protected]> wrote: > I'd say it's the safest if Adam additionally attach the patch to the jira to > make sure it's his explicit intention. Doing this only costs a minute and > then it's 100% clean. > Remember that anyone can commit with a foreign email and username on github... > If the patch is identical to the git fetch then you can of course take the > git route directly to apply it. > > > I know this is a bit of a paranoia mode, but it's the cleanest and safest way. > > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Dan Haywood <[email protected]> >> To: [email protected] >> Cc: >> Sent: Thursday, July 12, 2012 5:45 PM >> Subject: ISIS-233 fix from Adam via github >> >> Hi all, >> >> Just keeping everyone in the loop on this... >> >> ... Adam Howard, who's been doing great things with his JS client for the >> RO viewer in Isis, has also picked up on ISIS-233 and started to make some >> improvements to the Isis codebase. >> >> At the same time, I've also been maintaining a clone of Apache Isis on >> github [1]; in fact my own commits to ASF SVN are done from a git clone on >> my PC. If you're interested, the magic commands that I use to the commits >> on my local GIT repo up to SVN are: "git svn rebase" then "git >> svn dcommit". >> >> Whenever I do this I then do a "git merge remotes/github/master" >> followed >> by "git push github"; this pushes out the latest commits out to [1] >> also. >> >> Anyway, back to Adam's work, whose making his changes within git from his >> own fork of my github clone. With his first fix done, he sent me a pull >> request [2]. I've reviewed that, and it looked good, so pulled it down to >> my own local git repo. >> >> I had also asked Adam to sign an ICLA; this is registered on file. My >> understanding therefore is that his change can be applied in this way; >> there's no need to attach a patch to the ISIS-233 JIRA ticket. >> >> So, that's what I've done; I've gone ahead and git svn >> rebase/dcommit this >> pulled in change. >> >> Congrats, Adam... you are now formally an Isis contributor; see this SVN >> commit [3]. Unfortunately git-svn strips out the credit to you; unlike git, >> svn doesn't distinguish between author and committer. >> >> ~~~ >> Mentors... I hope I have all the above ok. But please advise if I've made >> a mistake anywhere. >> >> ~~~ >> Adam... following on from the above, now that I've pushed your change back >> out to my github clone, you're going to find that your change will have >> been rebased (ie reapplied as a different branch to the work you did). >> You've therefore got a choice: >> * you can either do a "git merge" in your repo, which will unify the >> two >> branches (as a no-op, probably) >> * or, and probably better, you should reset your master back to last common >> commit (ie wherever master was at the point you started work), and then >> fast forward onto the new commit that you'll have fetched from my clone. >> Your previous commits will become orphaned and eventually garbage >> collected. >> >> I hope that makes sense... This little picture of my current "gitk >> --all" >> might help [4] if not. >> >> Dan >> >> >> [1] https://github.com/danhaywood/apacheisis >> [2] https://github.com/danhaywood/apacheisis/pull/1 >> [3] http://svn.apache.org/viewvc?view=revision&revision=1360714 >> [4] http://danhaywood.com/?attachment_id=1019 >>
