Lets have a git master branch and at some moment lets fork branch for release (release branch will be called R1). Sometimes I need to push commit to both of them(master and R1). Usually I work on master branch, when I'm done I test it, cherry-pick to R1, test it there and push to both of them.
I would like to have in R1 commit reference to master branch. This is done by cherry-pick -x. However, this approach works ONLY when I push to master branch and then cherry-pick from master to R1. Let say that testing take too much time and I want to have master and R1 in sync as much as I can ( I want to minimize time gap between pushes), so I would like to push simultaneously. In this way I can not get reference (-x in cherry-pick), because hash will change while doing rebase in R1 (can not use merge). Is there any way how to automatize this, so I will have correct hash in R1 description? Something like hash predicting?
Is there any way how to automatize this, so I will have correct hash in R1 description? Something like hash predicting?
The short answer is no.
The longer answer is still no, but you might not need to predict the hash. The issue here is that you are copying some fix commit—let's call this F—from master to another branch. Let's call this -x cherry-picked copy commit Fx. You may also end up copying the fix commit to a new fix commit because you are avoiding using git merge in this work-flow, so if master has acquired new commits, you use rebase to cherry-pick F into a new commit F' that you will add to master, and now you want to replace your Fx—your cherry-picked copy of F—with a cherry-picked copy of F'.
So, you can just do that. If you rebase commit F to make F', strip Fx from the other branch and re-run git cherry-pick -x to copy F' to Fx'. You already know which commits these are, because you have the original hash ID of F and cherry-picking it (via rebase) produces F'; and you have F's hash ID in Fx. The drawback is that this re-copies any commits after Fx on the other branch, since "strip Fx from the other branch" can be nontrivial.
(An alterative approach, one that avoids all this fussing-about, is to merge the fix into both branches. See How to do a partial merge in git? and the linked blog articles.)