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