[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ptp-dev] Merge policy reminder
|
If one isn't using the git merge, git doesn't record the version as merged. That means that the next time git merge is used, git tries to merge the commits which were already copied manually. As long as no conflicts occur this doesn't matter because git can detect that the identical change was done in both branches. But if any conflicts occur, having copied a change manually (or cherry-picked) makes it unnecessary complex compared to a situation where everyone is following the same merge strategy. Thus I strongly suggest that one merge strategy is used by everyone.
The reason I suggested the merge (instead of the cherry-pick) strategy is that as far as I can see there is a consensus that it is the better strategy. See e.g.:
My personal two main point why I think that a merge strategy is better are:
- With cherry-pick it is possible to forget to cherry-pick it into the other branch. If all bugfixes are always first introduced into the release branch, it can never be forgotten to be merged into master (because merge automatically takes everything since the last merge).
- Every change only appears once in the history. Thus one has a 1-1 mapping between a change in the code and a commit.
But it is much more important to have the same merge strategy then the best one. Thus even if we decide on using cherry-pick strategy that would be better than the current situation.
Roland
On Wed, Feb 8, 2012 at 9:44 AM, Chris Recoskie
<recoskie@xxxxxxxxxx> wrote:
I don't trust the merge, so I'm doing what Dave is doing. Creating changes in one workspace, creating a patch from that, and then applying that patch to the other workspace. Basically, the exact same thing I did with CVS.
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
Greg Watson ---02/07/2012
08:06:09 PM---Dave, I'm doing essentially the same as you except:
From: Greg Watson <g.watson@xxxxxxxxxxxx>
To: Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
Date: 02/07/2012 08:06 PM
Subject: Re: [ptp-dev] Merge policy reminder
Sent by: ptp-dev-bounces@xxxxxxxxxxx
Dave,
I'm doing essentially the same as you except:
1. If I have changes that I want in both branches, I always work in ptp_5_0 and then later merge to master.
2. Once I've committed the changes to ptp_5_0, push them.
3. Switch to the master workspace, pull, then Team>Merge.
4. At this point you may get merge conflicts, in which case you resolve them, add the conflicted files (Team>Add to index), commit and push.
The last two steps are probably easier than applying the changes to the second workspace, especially if there are a lot.
Greg
On Feb 7, 2012, at 7:42 PM, Dave Wootton wrote:
I've just has a couple updates since the git conversion so I'm not sure if my process is a correct way to handle commits
I cloned the git repository twice, selecting only ptp_5_0 for one clone and only master for the second
I created two workspaces, one pointing to the ptp_5_0 clone and the second to the master clone
Before changing code I'll run a pull to make sure I have latest git code in my clone repository
I'll make my changes and test in one workspace until I am satisfied I have working code
Then I'll commit/push the changes in that repository
After that I manually make changes in the second workspace, retest as needed, then commit/push those changes
I realize this is probably not the most efficient way to do things, but at the moment I'm not working on a lot of changes and the whole git concept is new to me. So this sequence works for me as long as I'm not doing anything that breaks the process and causes
later merge problems.
Dave
|
[ptp-dev] Merge policy reminder |
Greg Watson |
to:
|
Parallel Tools Platform general developers
|
02/07/2012 01:51 PM
|
Please respond to Parallel Tools Platform general developers
|
|
|
--
ORNL/UT Center for Molecular Biophysics
cmb.ornl.gov865-241-1537, ORNL PO BOX 2008 MS6309