From 0fdbc0daadb0027761bb74cecb7c992adf171f15 Mon Sep 17 00:00:00 2001 From: Drew DeVault Date: Sun, 30 Sep 2018 09:58:34 -0400 Subject: Update send-email guide --- git.sr.ht/send-email.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/git.sr.ht/send-email.md b/git.sr.ht/send-email.md index b45d49b..9e6e6a9 100644 --- a/git.sr.ht/send-email.md +++ b/git.sr.ht/send-email.md @@ -130,6 +130,23 @@ submit the next version of your patches, use `git send-email` normally, except: [amend]: https://www.git-scm.com/docs/git-commit#git-commit---amend [git-rebase]: https://www.git-scm.com/docs/git-rebase +## Pulling from upstream + +As you continue to work, you may want to pull from the upstream, and you +almost certainly don't want to create a merge commit when you have WIP or +unmerged patches in your history. To this end, you should generally use `git +pull --rebase` to fetch the latest changes from upstream. + +If you get a conflict, read the information git prints. You have two choices - +skip the patch or fix it. If your patch has already been merged, the maintainer +likely made some minor changes that prevents git from detecting it's the same +commit you have locally - in this case, just `git rebase --skip` the patch. If +your patch still hasn't been merged upstream, you should resolve the conflicts +in your editor, using `git add some/file.c` to mark the conflicts as resolved, +and then using `git rebase --continue` to move on. You will probably want to +send a `-v2` patch upstream when you're done - any conflicts you resolved, your +maintainer will have to address, too. Save them the time! + ## Extra tips Here are a few extra tricks you might find useful with `git send-email`. -- cgit