Changes between Initial Version and Version 1 of GitRejectedPatch

Timestamp:

Jul 29, 2013, 1:58:20 PM (11 years ago)

Author:

Piero Campalani

Comment:

Copy dev-list discussion

GitRejectedPatch

@@ +1 @@
+= Dealing with rejected patches =
+
+It can often happen that a patch you submitted to the [http://rasdaman.org/patchmanager Patch Manager] gets rejected by our benevolent dictator, especially if you're a new dev and you are not that familiar yet with the rasdaman [http://rasdaman.org/wiki/CodeGuide coding guidelines].
+
+In case you are not familiar with `git` neither, here's a couple of examples of possible solutions that apply to such situations.
+
+SCENARIO: you formatted a patch `pZ` for commit `Z` in your local branch `my_branch` on top of `A`.
+The `master` branch is a clean and synced copy of the `origin/master` remote branch, hence the public HEAD of rasdaman:
+
+{{{
+  o-------o-------A-------B-------C  [master] -> [origin/master]
+                   \
+                    \   X--> rejected!
+                     \ /-pZ
+                      Z  [my_branch]
+}}}
+
+This is usually a recommended developing workflow, so if you worked directly on your local `master`, you might want to switch to this layout:
+
+{{{
+#!sh
+$ git stash
+$ git checkout -b my_branch master
+$ git checkout master
+$ git fetch origin
+$ git reset --hard origin/master
+HEAD is now at `D' <ticket:XYZ - Brief description of this patch>
+$ git branch
+ * master
+   tmp
+}}}
+
+Now the local `master` is synced with the patches that surely in the meantime were accepted in the [http://rasdaman.org/patchmanager Patch Manager].
+The other (local) branch `my_branch` contains your rejected commit `Z`.
+
+At this point there can be possible solution in order to rework on the patch:
+
+
+== 1. [Rebase &] amend ==
+
+If there are not patches which were applied since your rejection (ie `B` and `C`, see above), you can avoid rebasing: your `my_branch` branch is still on top of `origin`'s HEAD.
+
+Otherwise firstly you can move `my_branch` on top of `D`:
+
+{{{
+  o-------o-------A-------B-------C  [master] -> [origin/master]
+                   .               \
+                    .               \
+                     Z --(rebase)--> Z  [my_branch]
+}}}
+
+
+Afterwards, you can ''amend'' your commit: you can simply do it by modifying the files you are required to -- also files not previously included in the `Z` commit, stage them, then re-commit with the `--amend` option. You also have the chance to change the title of your patch during the process, eg `Z~`
+
+{{{
+#!sh
+$ vim file1 file2 ... fileN
+[do your stuff]
+$ git add file1 file2 ... fileN
+$ git commit --amend
+[you can change the title here now through your configured $GIT_EDITOR]
+}}}
+
+{{{
+  o-------o-------A-------B-------C  [master] -> [origin/master]
+                                   \
+                                    \
+                                    Z~  [my_branch]
+}}}
+
+Now you can reformat the patch:
+
+{{{
+#!sh
+$ git format-patch HEAD~
+0001-Z~.patch
+}}}
+
+Look out there are no other new patches in `origin`:
+
+{{{
+#!sh
+$ git fetch origin
+}}}
+
+Otherwise you can also try to see if your patch does not conflict with new ones: for instance while you were fixing your patch, a new one (`D`) was accepted:
+
+{{{
+  o-------o-------A-------B-------C-------D  [master] -> [origin/master]
+                                   \
+                                    \
+                                    Z~  [my_branch]
+}}}
+
+Instead of re-rebasing, you can try:
+
+{{{
+#!sh
+$ git checkout master
+$ git merge origin/master
+$ git apply --check 0001-Z~.patch
+}}}
+
+If no output is printed, then you can submit the new patch: http://rasdaman.org/patchmanager.
+
+
+== 2. Cherry-pick ==
+
+An other possible solution, which might be easier in case your rejected patch has already been followed by tons of other patches you formatted
+and that were accepted, is cherry-picking.
+
+For instance, a patch `pZ` (for your `Z` commit) was rejected, then a new patch from some other dev was accepted (`B`), and an other patch you developed afterwards on top of `Z` was accepted (patch `pW` for bringing local commit `W` to the public repo as `W~`):
+
+{{{
+  o-------o-------A-------B-------W~  [master] -> [origin/master]
+                   \             /----> accepted
+                    \   X-------/-----> rejected!
+                     \ /-pZ    /-pW
+                      Z-------W  [my_branch]
+}}}
+
+
+You can clone your master to a new branch and cherry-pick your `Z` but without creating a new `Z` ''commit'', just taking its changes:
+
+{{{
+#!sh
+$ git checkout master
+$ git fetch origin
+$ git merge origin/master
+$ git checkout -b my_other_branch master
+$ # Pick Z (refs/heads/my_branch~):
+$ git cherry-pick refs/heads/my_branch~ --no-commit
+$ git status
+[changes in Z are staged now]
+}}}
+
+{{{
+  o-------o-------A-------B-------W~  [master] -> [origin/master]
+                   \               \
+                    \   o-(c-pick)-(Z~) [my_other_branch]
+                     \ /
+                      Z-------W  [my_branch]
+}}}
+
+This way you can now fix the changes, re-stage them and commit.
+
+----
+
+Final note: conflicts can always happen, it's not your fault.[[BR]]
+https://duckduckgo.com/?q=git+rebase+conflict