Keith, I think I could simply edit the GS1 file, commit it and push that up to my fork. My main concern is with maintaining a clear workflow so we do not end up with multiple partially edited versions of any document. If you have no more edits for GS1, I'll do the two edits suggested by DiGro and push them up to my fork. In the future, how should we handle getting input from multiple reviewers? Since Git can't do a diff on these documents, we can't, I assume, use the usual git tools for conflict resolution. Should each reviewer download the doc from the author's fork, send the revised doc (with changes recorded and comments as needed) directly to the author, have the author integrate the changes into his/her version, possibly with changes from other reviewers, and push the doc as a new commit to the fork? I am not sure enough in my Git knowledge to call that a proposal but it is what we are doing in this case. Francis
On Tue, Mar 23, 2021 at 12:49 PM Keith N. McKenna <keith.mcke...@comcast.net> wrote: > On 3/21/2021 7:14 PM, GitBox wrote: > > > > FJCC commented on pull request #30: > > URL: > https://github.com/apache/openoffice-docs/pull/30#issuecomment-803677439 > > > > > > DiGro - thanks for reviewing the file and catching those errors. I > really appreciate you taking the time. I downloaded the file and I see the > edits you made. I'm not sure how Keith wants to handle responding to edits > needed in the pull request, so I will give him a chance to chime in. > > I will search future versions for multiple spaces. I should have > realized that was needed. > > > > > > Francis; > > I see no reason that just attaching it to the pull request wouldn't > work. I am newbie at GitHub, so if anyone knows I reason that it > wouldn't, please speak up and let us know. > > Regards > Keith > >
