Dealing with rejected patches ¶

It can often happen that a patch you submitted to the ​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 ​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:

$ 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 ​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~

$ 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:

$ git format-patch HEAD~
0001-Z~.patch

Look out there are no other new patches in origin:

$ 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:

$ 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:

$ 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.
​https://duckduckgo.com/?q=git+rebase+conflict