incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: ISIS-233 fix from Adam via github
Date Sat, 14 Jul 2012 15:19:52 GMT
Hi Adam!

just a simple

$> git diff > ISIS-nnn.patch

where nnn is the Isis jira number to attach to.

As we need no git-am or stuff git-diff is good enough.

LieGrue,
strub



----- Original Message -----
> From: Adam Howard <howard.adam@gmail.com>
> To: isis-dev@incubator.apache.org
> Cc: 
> Sent: Friday, July 13, 2012 8:59 AM
> Subject: Re: ISIS-233 fix from Adam via github
> 
> 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 <struberg@yahoo.de> 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 <dan@haywood-associates.co.uk>
>>>  To: isis-dev@incubator.apache.org
>>>  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
>>> 
> 

Mime
View raw message