isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject ISIS-233 fix from Adam via github
Date Thu, 12 Jul 2012 15:45:02 GMT
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

I hope that makes sense...   This little picture of my current "gitk --all"
might help [4] if not.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message