I did the following:
git fetch upstream
git cherry-pick xyz
The picked commit had been applied cleanly except that in one of the files it had exactly the same changes I had already done in a previous commit so these changes were not reapplied.
Everything in terms of code is fine but I'd like to have the commit hash in my history. In my history it appears with a new name. Is this even possible? As far as I'm reading the git merge "ours" strategy it seems to be generally possible but how to do it for a single commit?
I want this so it is easier to identify later what commits does upstream
has that I don't have. At the moment in github network
view I see the cherry-picked commit as being something separate that I don't have.
Additional information:
What @CharlesB says makes sense to me. But how does merge -s ours
do the magic then? In this case it was not important for me to cherry-pick
. Because the change I wanted to take is only one and at the tip of the upstream/master
. So just to try it out I did: git merge -s ours upstream/master
Now doing git log --graph --pretty=oneline --abbrev-commit
I see something like:
* 9e8108b Merge remote-tracking branch 'mgencur/master' for better github netw
|\
| * aa7117d Fix displaying watchers/watching for incorrect user // this commit magically appeared after merge -s ours
* | ff05f8c Fix displaying watchers/watching for incorrect user // this is commit from cherry-pick of aa7117d
* | b7ca8ec older commit in my fork
* | <more commits in my fork>
|/
* 94d6870 Fix obtaining available users for testing purposes
* <older commits of upstream/master>
The same command before git merge -s ours
was looking like:
* ff05f8c Fix displaying watchers/watching for incorrect user // this is commit from cherry-pick of aa7117d
* b7ca8ec older commit in my fork
* <more commits in my fork>
* 94d6870 Fix obtaining available users for testing purposes
* <older commits of upstream/master>
As you can see after cherry-picking of commit aa7117d, there was no indication that aa7117d is already applied to my fork repo. But after a merge it is indicated it is in there although nothing in my files changed.
That makes me think that it is indeed possible to declare a number of commits included in a branch although they are not applied exactly as they were applied upstream.
update2: I see question How to merge a specific commit in Git and its best answer. So an explanation why it is not possible or it is not implemented would also be appreciated.
Commit hashes are unique to each commit, by definition.
When cherry-picking, you're creating a new commit, even if you apply the same modifications, because it has a different parent commit.
However you can add ask git to put a message in the cherry-picked commit message :
cherry-picked from commit
<original-sha1>
From the documentation:
-x
When recording the commit, append a line that says "(cherry picked from commit ...)" to the original commit message in order to indicate which commit this change was cherry-picked from. This is done only for cherry picks without conflicts. Do not use this option if you are cherry-picking from your private branch because the information is useless to the recipient. If on the other hand you are cherry-picking between two publicly visible branches (e.g. backporting a fix to a maintenance branch for an older release from a development branch), adding this information can be useful.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With