On Nov 11, 2011, at 2:23 AM, Roland Schulz wrote:
On Thu, Nov 10, 2011 at 9:24 PM, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
On Nov 10, 2011, at 8:41 PM, Roland Schulz wrote:
3. Change two files in ptp_5_0, push the changes, then only apply the change from one file to master.
The two files should be changed in two different commits. If they are not one should go back and fix the commit (Team->Reset->Mixed, 2xTeam->Commit)
This reduces the problem to: Make commits in ptp_5_0 and merge only some of them into master:
Merge all as before
Open History View
Right Click commit which should not be in master->Revert Commit
This is only an example of a much more complex problem I just had. In order to fix a single bug, I had to modify about 5 files in ptp_5_0, however two of these files had completely diverged in master, so there was absolutely no way to merge them using
a diff viewer. I had to manually piece them together from the changes in the other branch.
Are you suggesting that we should use multiple commits even when there is no logical need for it, like for each file that is modified? No. I would always keep logical changes together. I would then merge the whole commit. This makes the history understandable. Merging it doesn't force you to use the compare viewer. You can resolve it any way you want - including starting from the unmerged and than coping the changes manually (as you have done). And than mark it as merged by adding it.
Another question about merging. Suppose I make a commit, and 50 other people make commits which are all pushed upstream to the 5_0 branch. When I merge with master, I'm going to merge all 51 commits right? That means I have to manually work out which of each of the 50 commits should merged and which shouldn't. Is that correct?
Greg
|
