shawnajean/pre-hugo-pr.md

## pre-hugo-pr.md

      
    Raw
  

              pre-hugo-pr.md
            
          
Add user's remote to your local system. Scroll down to the bottom of the conversation view in Github and look for text like: Add more commits by pushing to the add-path-type branch on xlgao-zju/website.
The first bolded item is the branch name and the second bolded item is the repo name. These are each links. Copy the URL for the second link. Go to the command line and add the remote:
git remote add REMOTENAME <URL>
It doesn't really matter what you call the remote.


Fetch both the upstream and the remote:
git fetch upstream; git fetch REMOTENAME


Check out the branch (first bolded thing from step 1) at the command line. If you don't already have a local branch with the same name, do it like this, and it creates a local branch that tracks the branch in the user's fork. It's magic (you don't need the -b on the checkout command).
git checkout BRANCHNAME
If you already do have such a branch locally, it's a little trickier. Create a new (differently named) branch based on their branch.
git checkout -b YOURBRANCHNAME REMOTENAME/BRANCHNAME
You'll also need to push differently, later on.


Go back to Github and figure out the real commit(s) in their PR. Usually it is only the latest commit or maybe the latest 2 if they had already addressed feedback before the Hugo migration. You'll cherry-pick these commits back onto the rebased branch later.


In the command-line, hard-reset the branch to the same state as the current state of upstream/release-1.11.
git reset --hard upstream/release-1.11


Back in the Github UI, copy the SHA of the oldest commit to cherry-pick. In the command-line, cherry-pick it:
git cherry-pick SHA
There will be conflicts, specifically due to the fact that all the docs files moved from /docs/ to /content/en/docs/. Use the git status command to see the conflicts.
As an example, look at the following output:
	deleted by us:   docs/reference/setup-tools/kubeadm/kubeadm-init.md

Using OS utilities, move the file to the right place. This will effectively overlay the new content on top of the existing file.
mv docs/reference/setup-tools/kubeadm/kubeadm-init.md content/en/docs/reference/setup-tools/kubeadm/
Use git add to add the newly-changed file.
git add content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
Use git mergetool to accept the deleted version of the /docs/ file.
git mergetool

Merging:
docs/reference/setup-tools/kubeadm/kubeadm-init.md

Deleted merge conflict for 'docs/reference/setup-tools/kubeadm/kubeadm-init.md':
  {local}: deleted
  {remote}: modified file
Use (m)odified or (d)eleted file, or (a)bort? d
Do git status and verify that everything you want to be green is green. Continue the cherry-pick.
git cherry-pick --continue


Repeat step 6 for any additional commits you need to cherry-pick.


Force-push the branch into the user's fork. If your local branch has the same name as the user's fork's branch, this is easy:
git push -f <REMOTE-NAME> <BRANCHNAME>
If the local branch has a different name (because you had a local naming conflict), use this syntax:
git push -f <REMOTE-NAME> <LOCAL-BRANCH-NAME>:<FORK-BRANCH-NAME>


The PR will update and should no longer show any conflicts, and should now only show the correct number of commits. Let the user know what you did and how to proceed. I developed the following template for this:
The underlying structure of the docs repository has changed due to the recent
Hugo migration. Specifically, all the files previously under `docs/` are now in
`content/en/docs/`. I have rebased your PR without changing any of your work, so
that your changes are modifying the affected files in the new location, so this
PR is now reviewable again.

**If you were using Github's web UI rather than a local Git client, you can stop
reading and continue working in this PR.**

If you use the Git command-line client, you will need to make sure your local
branch is up to date with your fork. **If you have local commits that have not
been pushed to your fork, it may be complicated to get them back.** Do `git log`
and note their commit hashes for later.

Assuming your your fork's remote is called `origin`, hard-reset your local
branch to be the same as your fork's branch:

\```bash
git fetch origin; git reset --hard origin/rm-in-tree-gpu
\```

**If you didn't have local commits, you're now ready to keep working on this PR
locally. You can stop reading now.**

If you did have local commits, cherry-pick them from oldest to newest. **For
each commit that needs to be cherry-picked:**

\```bash
git cherry-pick <HASH>
\```

You will need to resolve conflicts in these cherry-picked commits, which
involves moving your modified files into the correct new location. All the
content in `docs/` moved to `content/en/docs/`, so you can move your local files
accordingly:

- Do `git add` for each of the moved files
- Do `git mergetool` and accept the
deleted rather than modified file
- Continue the cherry-pick by doing `git cherry-pick --continue`


When you've cherry-picked all local commits back onto the local branch, push the
branch (with new commits) to your fork. You should not need to force the push.


Actually review their PR. They probably need to do at least the following:

Use Hugo shortcodes for admonitions and figures
Update all URLs to start with /content/en/docs where they currently start with /docs


Optionally, remove their remote and your local copy of their branch.
git remote rm REMOTENAME
# Because you can't delete a branch you have checked out
git checkout master
git branch -D BRANCHNAME