On Tue, Feb 23, 2010 at 6:15 PM, Robert Osfield <[email protected]>wrote:
> On Tue, Feb 23, 2010 at 4:50 PM, Tim Moore <[email protected]> wrote: > >> You're assuming that the submission is actually worthy of being applied ;) >> >> With a context diff, it's often easy to see by inspection that the >> submitter is off in the weeds, or to quickly determine that the patch is >> worth further study. This is from the point of view of someone who might >> give feedback on a patch rather than check it into the mainline sources. You >> might consder the work saved if people were doing more of that before you >> took on the individual submissions yourself. >> > > A quick diff/patch in an email for quick review and the real file as an > attachment can be effective route. Diff's on their own are right pain in > butt. I've tried diff's over the last decade and they really are pain in > the butt. Please don't keep trying to tell me that they have value when I > know from lots of experience that they are often really bad to deal with. > > I'm pretty fed up with have to repeat this stuff over and over. Diff's > don't work form me and they never will. The accumulated bad experiences I > have had with diff over the years me really detest it as form of patches. > You don't have to convince me, or even respond. I was just explaining my personal reaction to osg-submissions. By the way, I do attach the output of git format-patch to my submissions, as well as the complete files, in case others find it useful. > > >>> This round trip takes time, and sometimes the reply never comes. I >>> continuously try to reduce the amount of time dedicated to communication, >>> the amount of downtime between. It's my experience that diffs don't help. >>> Whole files, even ones out of date can be far more useful than a broken and >>> useless patch file. >>> >> If the reply never comes, then you've saved yourself the trouble of >> applying the patch... >> > > Well.. except it might be fixing a bug that we want fixed... there are > number of submissions like this hanging in osg-submissions awaiting > clarification. > As a general rule, if the submitter is competent, they will submit a patch that merges. Generally one hopes for patches from competent submitters. But "laisse tomber" as they say here. > > > >> >>> Given how pressed I am for time, I really do care about waste minutes >>> here or there. Whole files wins hands down for me. >>> >>> Now git might handle things better, but unless we can do a graphics diff >>> against the trunk then we are still stuck with having to apply to branch >>> locally and then doing a graphics diff and merge. >>> >>> git format-patch, the command for submitting patches from local work, >> does include info that makes it more reliable to merge the patches against >> the current head of the maintainer regardless of the original versions used >> by the submitter. >> > > Is there a graphics tool for helping handling patches? > Not built in, but there interfaces to them. the man page for "git-mergetool" mentions xxdiff among others. > > Are there tools for extracting whole changed files as well? > I don't think so, but it's very easy to extract the list of files changed in a commit, so one could write a trivial script to bundle up the files. Tim
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
