On 6/4/19 8:42 AM, schoone...@gmail.com wrote:
On 04/06/19 13:05, emc-developers-requ...@lists.sourceforge.net wrote:
Date: Mon, 3 Jun 2019 14:45:28 -0500
From: John Thornton<bjt...@gmail.com>
To: EMC developers<emc-developers@lists.sourceforge.net>
Subject: [Emc-developers] Merge Just One Commit Up
Message-ID:<21236f20-9c1c-944e-ab39-bed182e41...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
How do you merge just your special commit from 2.7 to 2.8 to master?
I use git, git-gui, and gitkraken.
Thanks
JT
From whatever branch you want it included in:
git cherry-pick <SHA of commit you want>
This does have the effect of getting that single commit into the
destination branch, but i think it would be a mistake to use cherry-pick
for the use case John is asking about.
Cherry-pick creates a new commit with the same patch and commit message
as the original but with a new parent (the destination branch tip that
you're cherry-picking onto). This can cause trouble in two ways:
1. It makes it harder to search for changes with things like "git branch
--contains $SHA". The cherry-picked commit won't show up, since it's
got a different SHA than the original.
2. It can introduce confusion during a later proper merge. The old
source branch (2.7 in John's question) will still get merged into the
destination branch (2.8) at some point in the near future. Having the
same patch already applied, with any merge conflicts resolved, can cause
more merge conflicts.
Since the real merge has to happen anyway, IMO it's much better to not
mess with cherry-picking and just do the merge.
All of this advise is specifically for the situation John asked about,
where a commit from an older branch needs to move up to newer branches.
In this situation, merge is preferable over cherry-pick.
In other situations, for example when a commit was made on a newer
branch (let's say 2.8) but really belongs on an older branch (2.7),
cherry-pick is the correct answer. The work flow in this situation
would be to cherry-pick the commit from 2.8 to 2.7, then merge 2.7 back
into 2.8 to address any merge conflicts that might arise.
--
Sebastian Kuzminsky
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
