= 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