incubator-isis-dev mailing list archives

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


----- 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