1

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?

Ondrej
  • 567
  • 5
  • 14
  • The real problem here is your workflow, which seems to have the occasion to make a commit in a feature branch and then cherry-pick that commit back to master. If you had a proper merge or rebase workflow, you might not have to use cherry-pick at all. My vote is to fix your workflow, and then to avoid using cherry-pick unless absolutely necessary. – Tim Biegeleisen Oct 03 '18 at 08:16
  • Actually I can not push to R1 and then back to master. In the end of the day this will not fix my problem, I still need to test it and push it to both branches and have in R1 reference to master commit. – Ondrej Oct 03 '18 at 08:31
  • You can't really do this with cherry-picking, because cherry-picking creates a _new_ commit. That commit may be functionally identical to the original commit, but, the SHA-1 is different. If you want to share the same commit, then you'll need something like merging or rebasing. – Tim Biegeleisen Oct 03 '18 at 08:33
  • I think we are not on the same page. I do not want to share the same commit at all, I just want to have reference in commit2 in R1 to the commit1 made to master. If you make commit1 to master branch and then cherry-pick it with -x to R1, you will get something like __cherry picked from commit 98073c13...__ in the description, which is exactly what I want to have – Ondrej Oct 03 '18 at 08:41
  • So you're saying that you want to push the commit to `master`, then rebase `R1` on `master`, and someone automatically have that rebased commit from `master` have a reference added to the message? Is that right? – Tim Biegeleisen Oct 03 '18 at 08:56
  • I want to create local commit on master. Then I want to rebase/cherry-pick it to R1 (locally) and give to description of R1 commit hash (predicted hash) of master commit. I can not give hash of commit in master, because it will change upon pull & rebase. Then I want to push to R1 and master at once. – Ondrej Oct 03 '18 at 10:19
  • I don't think you can do this, because a commit message is part of the commit. So, you either get your extra note in the commit message on both `master` and `R1`, or you don't get it at all. But you _can't_ have the same commit, with the same SHA-1 hash, with two different commit messages. – Tim Biegeleisen Oct 03 '18 at 10:21
  • Two different commits could have same SHA1 hash actually, but this is another topic :) Yes, I know that I will not have *same* commit with the *same* SHA1 hash, the commits could be different but I wanted dynamic description which will change after push. That means it will have hash of local commit and after rebase it will change, so that the reference will stay. Something like pointer. – Ondrej Oct 03 '18 at 10:53
  • Well the thing is, if you rebase on `master`, then the commit _won't_ change, because Git will rewind your `R1` branch, and play that exact commit. What would change would be all your own `R1` commits. – Tim Biegeleisen Oct 03 '18 at 11:01
  • Commit will not change, but the hash will change. When you do rebase it will change hashes of local commits (and the reference in the description would be invalid) – Ondrej Oct 03 '18 at 11:10
  • Only commits which are _reapplied_ would change. If you rebase `R1` on `master`, then the commit you made to `master` would _not_ change. – Tim Biegeleisen Oct 03 '18 at 11:14
  • That is true, but when you type *git pul --rebase* (we can call it pull&rebase) git internally unwind all local commits, move HEAD to upstream branch and *reapply* all local commits. This will leads to rehash of every local commit in every pull&rebase, which cause invalidation of reference. This is my problem – Ondrej Oct 03 '18 at 11:18

1 Answers1

1

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.)

torek
  • 330,127
  • 43
  • 437
  • 552