First I would like to offer a huge thank you to Ben for making this tutorial. I really appreciate his efforts, because I am one of the members of his target audience. I'm continuing to try, but git is not clicking for me as well as I had hoped.

Here are some thoughts and questions that I had as I review Ben's work this morning when I attempted to do some editing of the doc files.

1. I like Ben's approach of presenting just one workflow to get new people like me up and running. I imagine as I learn more or use different tools, I might find different ways of working, but having one template of steps that always works that I can come back to after not touching the docs for a week or two would be nice.

2. I also appreciate that Ben focused the docs on Fedora as the environment. For a complete new person like myself, I'm looking to give back to Fedora as a thanks for what Fedora has enabled me to do with my computer, so I would like to test the documentation on Fedora and edit the documentation on Fedora. I also understand that there are other users that might be doing work for Fedora on other systems. Personally, I'm using Fedora 100% of the time at home, but I'm using Win10 and Ubuntu Mate at work. I think Ben is right though that for this "Quick Start Guide" for new users and contributors to Fedora it might be best to focus the docs just on Fedora.

3. https://fedoraproject.org/wiki/User:Bcotton/git-for-docs-writers#Before_every_contribution
- Would it be a good idea to add in this section the following additional command?

git push origin master

- The reason I ask is because I knew that my Pagure fork was out of sync because I couldn't see in the webview of my Pagure fork an update that I knew had been accepted by the Docs team. After running this additional command, I could see the changes in my Pagure fork webview. This way when I go to my Pagure fork webview I should see the exact same thing as what is appearing on the Fedora Master Pagure webview. I appreciated this confirmation that I had everything in sync.

4. The following question came up when I started making edits that I didn't have the time to finish today.
- I understand that ++git checkout -b branch_name++ puts me into my working branch that I have created.
- However if I need to close my text editor and come back to my edits later, how do I know if I'm still making those edits in my "work in progress" branch instead of my forked "master" branch?
- Do I fire up a terminal and just run ++git checkout -b branch_name++ again?
- Or is there a "status" type command that I would run from the terminal to know what branch I'm making my edits in?

Thanks again for providing this resource for a new contributor like me. I really admire the more talented and knowledgeable community members on the docs team who have helped me so far. I have gotten some great help in the fedora-docs IRC besides this mailing list. Thank you!

---------------------------- | Steve | | mowestusa@yahoo.com | ----------------------------


On Wednesday, December 18, 2019, 7:11:14 AM EST, Justin W. Flory <jflory7@gmail.com> wrote:


On 12/18/19 6:54 AM, Brian (bex) Exelbierd wrote:

> I have an alternative approach that I like that I feel like makes it
> easier to keep the fork in sync.  This feels like a huge point of
> friction for new users and this is hte only reason I am proposing it.
>
> 1. Go to Pagure to the docs repo and get the clone URL (this may be an
> https url and that is OK)
> 2. On your system clone this url: `git clone <docs repo clone url> -o
> upstream`
>     This will create the repo as a remote called upstream.  This is
> mostly a detail and can be glossed over
> 3. Fork the repo in the Pagure UI
> 4. Copy your fork clone url (git@...)
> 5. `cd <repo directory>
> 6. `git remote add origin <fork clone url>`
>
> At this point the master branch is linked to "upstream" and the fork is
> origin.  What this means is that, following hte rest of the directions,
> keeping the repo in sync is as simple as `git checkout master; git pull`

>

+1 to this tip! That's a clever trick to get master linked to a
different remote from other branches. It also makes feature branching
easier to understand when things are set up this way.

Today I learned :)

--
Cheers,
Justin W. Flory
justinwflory.com
TZ=America/New_York
Pronouns: he/him/his