Dave,
If you find that someone else has made a change without merging it, then you have no choice but to do the merge yourself and assume that it is ok. I think it would also be a good idea to email this list when this happens (I'll be doing that from now on.)
I'm not sure why your commit is not seeing any changes. Is there anything in the []'s after the plugin names (like Merged)? You try viewing history on something in the repository to see if the change is there. You could also try merging again, or try pushing to see what happens.
Greg On Feb 10, 2012, at 7:26 AM, Dave Wootton wrote:
Greg
I tried this with my changes for bug
371203. When I ran the merge the popup showed me two commit ids, one for
my change and the second for a change Vivian made. I didn't note the commit
id in the popup but I think it's a change for bug 371140.
Then I ran commit thinking I would get
a list of fixes to include/exclude but only got a message that there were
no changes to commit. I didn't want to merge changes I didn't make into
the PTP repository so I didn't do the push to upstream yet.
How do I proceed?
Dave
|
Re: [ptp-dev] Merge policy
reminder |
Greg Watson
| to:
| Parallel Tools Platform general developers
|
02/07/2012 08:05 PM |
Please respond to Parallel Tools
Platform general developers
|
|
|
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
| |
|
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
_______________________________________________
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
|