incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: ISIS-233 fix from Adam via github
Date Fri, 13 Jul 2012 08:26:00 GMT
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/

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