incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Howard <>
Subject Re: ISIS-233 fix from Adam via github
Date Fri, 13 Jul 2012 06:59:32 GMT
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

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.


On Fri, Jul 13, 2012 at 1:40 AM, Mark Struberg <> 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 <>
>> To:
>> 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]
>> [2]
>> [3]
>> [4]

View raw message