Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] Merge policy reminder

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

Sent by: ptp-dev-bounces@xxxxxxxxxxx

Please respond to Parallel Tools Platform general developers







I'd like to remind everyone that every time you commit something to ptp_5_0 you need to take some action to either merge or reject the changes on the master branch. If you don't do this, then the next poor sucker (usually me) has to try and resolve all the merge conflicts that are created.

Thanks!

Greg
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev


_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev


Back to the top