Mailing-List: contact isis-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: isis-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of howard.adam@gmail.com
 designates 74.125.83.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALJOYLHTyg3ofzRZEgiR4gMCbhN-T-Xw5p8fTSLVs3cfS5cGng@mail.gmail.com>
References: 
 <CALJOYLFDvrf396ubfbUbhVnoLPgU5TgYOPpnY028hvYPurBbUg@mail.gmail.com>
	<1342161623.98782.YahooMailNeo@web171503.mail.ir2.yahoo.com>
	<CAN5Lg04Pi800GZ9TobPjvG=2mUHUh++0=yntmNPt_W9hsNEhzQ@mail.gmail.com>
	<CALJOYLHTyg3ofzRZEgiR4gMCbhN-T-Xw5p8fTSLVs3cfS5cGng@mail.gmail.com>
Date: Fri, 13 Jul 2012 08:22:09 -0500
Message-ID: 
 <CAN5Lg06T-QUrYPmCdH6VP0PULiohc3SgbL9KZFBTqn1zVb-AGw@mail.gmail.com>
Subject: Re: ISIS-233 fix from Adam via github
From: Adam Howard <howard.adam@gmail.com>
To: isis-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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
<dan@haywood-associates.co.uk> wrote:
> On 13 July 2012 07:59, Adam Howard <howard.adam@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/