The possible merge conflicts and the content of the end result will be the same as the cherry-pick, you would obviously have to pick the content of that commit on top of your actual my/work branch.Īs you can see from the diagram : the merge base for the cherry-pick must be p, so you won't be able to create a PR against your initial my/work branch, which gives the same result as the cherry-pick.Of course, Cherrytree’s feature list goes on longer than the highlights above and even more on its wish list which you can look up on its website’s homepage.īoth Zim and Cherrytree are excellent wiki-style note-taking applications but Cherrytree has more functions available to users after a clean installation than Zim does.Īnd though Zim users can always make use of extensions, Cherrytree seems to be more user-friendly to me. What to do with the result of this merge ? You would merge cherrypick/source in cherrypick/target You would want a branch cherrypick/source at eacf32 : git branch cherrypick/source eacf32 # ('-soft' will keep all the differences as staged changes) : # use 'reset -soft' to move to the parent of eacf32 You would want a branch cherrypick/target, with the actual content of my/work, grouped as one commit on top of p - the parent commit of eacf32 : # start from your branch (you will have the expected content) : # 'git cherry-pick eacf32' will try to resolve this merge : Suppose you run git cherry-pick eacf32 from branch my/work : # 'p' marks the parent commit of eacf32 : Here is my go at illustrating the merge operation performed by git cherry-pick : A cherry-pick tries indeed to merge two patches together, but you will not be able to create a merge request on your work branch that does the same action as the cherry-pick.
0 kommentar(er)
