On 13 July 2012 07:59, Adam Howard <[email protected]> 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/
