[GitHub] [openoffice-docs] orcmid edited a comment on issue #40: 2nd review remaining files

[GitBox <gi...@apache.org>]

orcmid edited a comment on issue #40:
URL: https://github.com/apache/openoffice-docs/issues/40#issuecomment-927172205


   The normal approach would be to create a personal branch of the repo to protect your changes.  Then, in whatever cloned upstream branch you are working in, do the Fetch Upstream operation.   This should walk you through any merge conflicts.
   
   You might not need the personal branch you created for safety.  You could try merging it back in or simply copying the modified document you have to the updated clone.
   
   This may be all too wonky.   
   
   I agree about the choices of binary formats (and branches) that defeats the ordinary use of GitHub.
   
   **However, you can submit a pull request** to the upstream open-office-docs repository (i.e., here).   When you are ready to submit the changed files you have made on the same branch as the project, just use the pull request operation in the GitHub menu when your GitHub openoffice-docs clone is open in your Browser.  It is pretty straightforward and doing it with only a single (or very few) changed file(s) should work.  Then the official contributors can review your request, give you feedback, figure out the merge, etc.  Not to worry.  You can't mess anything up.
   
   I don't know of any necessity to be an Apache committer to operate this way.  That would completely defeat the value of using GitHub.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: doc-unsubscribe@openoffice.apache.org
For additional commands, e-mail: doc-help@openoffice.apache.org