You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2012/07/12 17:45:02 UTC
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
Re: ISIS-233 fix from Adam via github
Posted by Mark Struberg <st...@yahoo.de>.
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 <ho...@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 <st...@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 <da...@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
>>>
>
Re: ISIS-233 fix from Adam via github
Posted by Adam Howard <ho...@gmail.com>.
The diff is now attached to the JIRA ticket.
I'll try branching next time as you suggested. It sounds cleaner.
Adam
On Fri, Jul 13, 2012 at 3:26 AM, Dan Haywood
<da...@haywood-associates.co.uk> wrote:
> On 13 July 2012 07:59, Adam Howard <ho...@gmail.com> wrote:
>
>> 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.
>>
>
> The pull request you sent me had links for these directly:
>
> https://github.com/danhaywood/apacheisis/pull/1.patch
> https://github.com/danhaywood/apacheisis/pull/1.diff
>
> So, you could download either and attach to the JIRA (ideally, x-ref this
> pull request URL; I presume its a permalink).
>
>
>
>>
>> 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.
>>
>
> Yes, it is complex, but that's because of the git-svn integration. If we
> were solely in GIT-land, it'd be much easier. But until then....
>
> Using git-svn requires that a rebase is performed. It's this rebase that
> messes you up (and it messes me up similarly with any work I do in my GIT
> repo). I haven't found a way around this, and to be honest I don't think
> that there is a way around it.
>
> Should you use a branch? Yes, that might be a good idea, if only because
> it'll make it easy for you to rewind back in time in order to do a
> subsequent pull from your origin (ie my github copy of Isis).
>
> So, let me sketch out a process that I think will work for you.
>
>
> 0. assuming that you've done a "git pull" and that your master branch is
> pointing to the same point as remotes/origin/master, and this is also your
> HEAD. (If you use gitk --all, you can see all the branch labels, and HEAD
> is the commit coloured yellow).
>
> 1. git checkout -b newstuff # creates a new branch and switches to it.
> In gitk, you'll see a new label pointing alongside the others
>
> 2. start working away, git add ... new files etc etc
>
> 3. git commit -am "ISIS-xxx: yada yada" # this will move the "newstuff"
> label to the new commit, but leave "master" where it was.
>
> 4. create a pull request [1]. Do this by switching branches first to
> "newstuff", then creating the pull request.
>
>
> At this point I now apply the pull request to my git local repo, then do
> git svn rebase / git svn dcommit to apply the changes to SVN. Finally, I
> do a git merge "remotes/github/master" then a "git push github" to push it
> back out to my github repo, ie to your origin.
>
>
> 5. git fetch origin # This will result in a new chain of commits coming
> in from origin, all starting from where your "master" branch still is. If
> you do a fetch rather than a pull, you can preview those new commits using
> "gitk --all".
>
> 6. git checkout master # switch to master
>
> 7. git merge remotes/origin/master # should do a fast-forward merge, ie
> simply move your master branch up to the latest.
>
> 8. git branch -d newstuff # you don't need this original branch
> anymore, since the change is back in via steps 5~7.
>
> As a small improvement on the above, you might want to name your branch
> "ISIS-xxx" rather than "newstuff"... that way it's clear what it relates
> to. It'll probably make the pull request more self-describing also.
>
>
>
> Hope that makes sense
>
> Dan
>
>
> [1] https://help.github.com/articles/using-pull-requests/
Re: ISIS-233 fix from Adam via github
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 13 July 2012 07:59, Adam Howard <ho...@gmail.com> wrote:
> 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.
>
The pull request you sent me had links for these directly:
https://github.com/danhaywood/apacheisis/pull/1.patch
https://github.com/danhaywood/apacheisis/pull/1.diff
So, you could download either and attach to the JIRA (ideally, x-ref this
pull request URL; I presume its a permalink).
>
> 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.
>
Yes, it is complex, but that's because of the git-svn integration. If we
were solely in GIT-land, it'd be much easier. But until then....
Using git-svn requires that a rebase is performed. It's this rebase that
messes you up (and it messes me up similarly with any work I do in my GIT
repo). I haven't found a way around this, and to be honest I don't think
that there is a way around it.
Should you use a branch? Yes, that might be a good idea, if only because
it'll make it easy for you to rewind back in time in order to do a
subsequent pull from your origin (ie my github copy of Isis).
So, let me sketch out a process that I think will work for you.
0. assuming that you've done a "git pull" and that your master branch is
pointing to the same point as remotes/origin/master, and this is also your
HEAD. (If you use gitk --all, you can see all the branch labels, and HEAD
is the commit coloured yellow).
1. git checkout -b newstuff # creates a new branch and switches to it.
In gitk, you'll see a new label pointing alongside the others
2. start working away, git add ... new files etc etc
3. git commit -am "ISIS-xxx: yada yada" # this will move the "newstuff"
label to the new commit, but leave "master" where it was.
4. create a pull request [1]. Do this by switching branches first to
"newstuff", then creating the pull request.
At this point I now apply the pull request to my git local repo, then do
git svn rebase / git svn dcommit to apply the changes to SVN. Finally, I
do a git merge "remotes/github/master" then a "git push github" to push it
back out to my github repo, ie to your origin.
5. git fetch origin # This will result in a new chain of commits coming
in from origin, all starting from where your "master" branch still is. If
you do a fetch rather than a pull, you can preview those new commits using
"gitk --all".
6. git checkout master # switch to master
7. git merge remotes/origin/master # should do a fast-forward merge, ie
simply move your master branch up to the latest.
8. git branch -d newstuff # you don't need this original branch
anymore, since the change is back in via steps 5~7.
As a small improvement on the above, you might want to name your branch
"ISIS-xxx" rather than "newstuff"... that way it's clear what it relates
to. It'll probably make the pull request more self-describing also.
Hope that makes sense
Dan
[1] https://help.github.com/articles/using-pull-requests/
Re: ISIS-233 fix from Adam via github
Posted by Adam Howard <ho...@gmail.com>.
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 <st...@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 <da...@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
>>
Re: ISIS-233 fix from Adam via github
Posted by Mark Struberg <st...@yahoo.de>.
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 <da...@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
>