Hi All, 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? Robert. On 20 May 2016 at 09:43, Robert Osfield <robert.osfi...@gmail.com> wrote: > Hi Jannik, > > Thanks for the info. Looks like my fix of the author name/email > address yesterday created all these problems with pull requests. > > I've developed rather a love/hate relationship with git and github. > Some things going really smoothly but then can turn around and bite > you and just throw lots of road blocks in you way, constraining you to > work with certain path or break things. So far git has created far > more work for me than it's saved. > > I find it a bit depressing that there is still so much more to learn > about git and github before I can safely master it. Personally I'd > rather just get on code, fix problems with the OSG itself rather > jumping through hoops to use tools that are "supposed" to help your > work. > > For now I have 30 pull requests to fix in some fashion as they aren't > in anyway useful as things stand. First step will be to get all those > who've made a pull request to fetch the new history then see what > happens on github. Perhaps it'll automatically fix things, perhaps > the author will have to resubmit. > > Do you know what steps do members of the community need to do to fix > things? Perhaps we can pass instructions on via comments of each pull > request. > > Submitted code to osg-submissions might not be perfect but it's been a > hell of lot more reliable and robust than github. > > Robert. > > On 19 May 2016 at 20:05, Jannik Heller <scr...@baseoftrash.de> wrote: >> Hi Robert, >> >> by fixing the author names you have essentially re-written the repository >> history. This means that everyone who submitted pull-requests in the past >> will have to manually rebase their changes on top of the new history. But >> it's not so difficult to do that if you know how to use the git rebase tool. >> >> The github document "Changing author info" (which I assume you were looking >> at?) does state this caveat: >> >> "Note: Running this script rewrites history for all repository >> collaborators. After completing these steps, any person with forks or clones >> must fetch the rewritten history and rebase any local changes into the >> rewritten history." >> >> In the future you may want to avoid rewriting history (i.e. anything that >> requires a force-push) since it does cause disruption for people that have >> already sent in changes. But it's not a big deal now since github is not >> even the official submission route yet. >> >> As for checking out the changes in pull requests that were not adapted, you >> can look at the author's repository (e.g. >> https://github.com/vivijind/OpenSceneGraph/commits/master shows the commits >> for PR https://github.com/openscenegraph/OpenSceneGraph/pull/68). In some >> cases it looks like the authors have deleted their repository, but you can >> still check out the pull request locally ( >> https://help.github.com/articles/checking-out-pull-requests-locally/ ) and >> from there look at the included commits. >> >> Cheers, >> Jannik >> >> ------------------ >> Read this topic online here: >> http://forum.openscenegraph.org/viewtopic.php?p=67161#67161 >> >> >> >> >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
