[osg-users] Submission/Pull Request problems on github

Björn Blissing bjorn.blissing at vti.se
Fri May 20 06:58:30 PDT 2016

robertosfield wrote:
> Hi Björn,
> I just checked, github still isn't giving my an option to reopen the
> pull request. Could you try another push of the request?

I have submitted my pull request again (it was the gitignore patterns for Visual Studio). 

robertosfield wrote:
> I'm struggling to get git to work in a way that allows me to do a
> proper review with the ability to graphically comparing sets of
> changes, for instance I have a set one pull request that has 88 files
> modified, alot of files but a small number of relatively minor changes
> such a variable renames.  I've done a quick review online and spotted
> that one instance so far where this renaming actually introduces a
> bug.
> I've experimented with pull in the 3rd party clone of the
> openscenegraph that contains these modfications and successfully
> created a patch and applying this to a local branch on my
> openscenegraph, it applies fine but contains the known error, perhaps
> others that I'll spot once I go through another full review.  This is
> where graphically diff is crucial.  git makes it dead easy to merge
> many file changes with a couple of lines of git on the command line,
> but as yet I'm struggling to find a way to get git to allow me to
> merge one file at a time and presented with a graphics diff that
> allows me to individually accept/discard changes.
> Will I need to write my own script to do this?   To do this I'd need
> to get to spit out a list of all the modified files in a form that I
> can pass into a script.
> As things stand I am not prepared to merge a big patch with an unknown
> number of bugs introduced simply because git makes it convenient to
> merge as is and makes it hard to spot errors and intervene.
> Thoughts, advice how to workaround these problems using git?

I agree that doing merges online using the GitHub platform is a very bad idea, except for trivial changes (for example changing a spelling error inside a readme file).

For all cases with source code I will fetch the pull request to my local machine and do the merge to my workspace. Then I can use my favorite diff tool as well as compile and test. If all my tests pass then I commit the merge to the master branch and push the changes to the online repo.

(The above workflow is pretty much identical to: applying a patch file -> test&compile -> commit to SVN.)


Read this topic online here:

More information about the osg-users mailing list