On Wed, Aug 08, 2007 at 22:56:33 +0100, Thomas Adam wrote: > On 08/08/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > Hi, > > > > On Wed, 8 Aug 2007, Thomas Adam wrote: > > > > > As for myself, I maintain _locally_ a few branches (branchX, branchY) > > > which dictate some bits and pieces I'm working on. Periodically, I > > > will tend to merge either merge to master and then push those changes > > > out. So far so good... > > > > > > But, I've now come up against a case whereby if one of my colleagues > > > changes a file (call it fileA) in branch master, and, in the course of > > > my working in branchX means i modify fileA also, when I come to merge > > > branchX into master I find the original change in master (as submitted > > > by my colleague) being reverted by my changes in branchX. > > > > I have a hard time seeing that. If you touch the same code, > > unidentically, merge-recursive will not be nice to you: it will show > > conflicts, and you have to resolve them. > > > > Or do you use "-s ours"? > > No, nothing like that. I have had a situation where by a merge from > branchX to master has resulted in master's changes to fileA being > reverted based on what was in the contents of fileA in branchX -- this > is of course wrong though -- master hsa the most recent copy. My > solution therefore was to cherry pick the commit into branchX and > remerge into master. This is why I was forced to ask about whether or > not git-rebase was the correct way to go. Git rebase is a correct way to go, with advantage of resulting in simpler history and disadvantage of slightly harder conflict resolution (since you merge commit-at-a-time rather than in one big block). However merge is equally correct way to go. Either there is a bug in merge -- which I would consider rather unlikely, though not impossible -- or you actually did, probably unintentionally, undo the master's changes. This might happen if: - You try to merge, either in --no-commit mode, or have a conflict, so it's not commited. - Then decide you don't want to resolve now and undo the changes by checking out the files, but don't clean the information about merge in progress. - Commit some changes in such state. This records a merge, that revers all changes from master. Similarly attempt to merge just part of files would result in a problem like you describe -- merging is only supported on whole trees. > Although I suppose this leads me to the ancillory question of: At the > point I merged master into branchX did this cause any problems for any > future merges of branchX into master? I cannot recall if this > "revert scenario" I describe to master happened pre or past my merge > of master into branchX, but I suspect it was after I had merged master > into branchX. Merge is completely symetrical operation in git. Merging branchX into master and merging master into branchX is the same for all purposes whatsoever (though you can tell how you did it by order of the parsent in the commit objecT). Repeated merges between two branches are allowed and always correct thing to do. However, you should be aware, that attempt to reject a change will be recorded as a reversal and merged as such. You can try visualizing the situation before the merge with: gitk master-before-merge...branchX-before-merge (or equivalently: gitk merge-result^...merge-result^2) print the base revision with: git merge-base master-before-merge...branchX-before-merge (or equivalently: git merge-base merge-result^...merge-result^2) look it up the graph and contemplate at what could have caused the reversal. I expect you can't disclose the code to ask anybody help you with that. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
