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. 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. -- Thomas Adam - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
