Needs for Clarification Concerning the Readme Steps

[firstcontributions]

Needs for Clarification Concerning the Readme Steps

[LePetitRenard]

Ok, I'm working on making something...Let's see what you think when I request a pull...

[Roshanjossey]

@LePetitRenard: Thanks a ton for bringing this to my attention. Kudos on drafting an awesome issue. You're awesome.

I've got feedback from people already that they missed seeing the point of Keeping your fork synced section. I didn't know that it had a destructive effect.

How about we take a third path where we extract that section out to a different file as additional information (or even remove it). Anyways it's not part of the simple success path to submit your first pull request.

Please share your thoughts on the above

[Roshanjossey]

I wanted to answer/ clarify some questions in your comment

I'm not sure if I'm supposed to type "git fetch upstream" every day, or what you mean by "it's synced"...if it's synced like an android with "sync on" or not.

This fetching and merging is only neccessary if you want to start working on something. It's good to start from how upstream (or the repo from you forked from) is now.
Your fork might not have recent changes that are in upstream.
For example if you go to your fork on github, you can see messages similar to
This branch is 1 commit behind Roshanjossey:master.
Fetching and merging is done so that you can start from there.

[Roshanjossey]

Furthermore, I don't know what would happen if I did git push upstream master. Do I simply get a request for a login/password which I won't have so it wouldn't matter, or will it push through to your main repo direct and mess up everyone else's code? (I actually don't want to try, just in case the latter applies hahahaha)

You'll get request for login/password or an authentication error. It wouldn't go through

[Roshanjossey]

@LePetitRenard: What is your thought on removing that section?

[LePetitRenard]

I think it's important to know how to delete a remote branch, I don't really want to delete it.
You'll see that, if I re-word a little the flow of the README: it can change quite a bit:

1. before the fork, I'll merge to master. Then deleting the local is ok.

2. Clarify what we're actually doing in the Sync process

3. Then...I'm left with the remote branch in the fork, I don't know how to make it work yet. I'm currently rewording the Sync process. I just hope an idea will flow when I arrive there :)

[tachyons]

💙 the way this issue is structured. The mentioned section is really valuable, problem is that potential danger is not properly communicated there. So I personally suggest to add warning symbol to potentially dangerous commands and explain the reason

[Roshanjossey]

@tachyons, @LePetitRenard has already submitted a pull request to address this. I could use a second pair of eyes there.

I was thinking about extracting this out to another document and adding it in next steps.
My thinking is that this portion is not part of submitting first pull request workflow.

[TheChronicMonster]

A little late to the party here, but better than never.

After scouring the interwebs a bit, I concur with @Roshanjossey to extract the second half of this repo to a different file as additional information. A beginner level 2, if you will.

I also concur with @tachyons to include a danger icon ☠️ and more blatant instructions to not proceed with the second piece until AFTER the pull request has been approved.

Reasons for such conclusions are as follows:
Per lullabot one should never delete unmerged remote branches. (Search "Never delete unmerged remote branches")

Per Seth robertson Periodic Maintenance of pruning branches is important. (Search "Do periodic maintenance")

There are a few different ways to achieve the desired results of the first-contributions. The important thing is that a workflow is agreed upon. There's nothing inherently wrong with get fetch upstream or git push origin master. In fact, I found advice to the effect of fetch and merge, don't pull.

In conclusion, the advice given in first-contributions is performant and relevant, but as @LePetitRenard demonstrated, prone to lead to deleted branches if not read closely.