Re: Workflow question: A case for git-rebase?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 8, 2007, 21:47 UTC
Message-ID: <Pine.LNX.4.64.0708082246370.21857@racer.site>
In-Reply-To: <18071eea0708081411p41eaa44ai105adaef0e4b10a5@mail.gmail.com>

Hi,

On Wed, 8 Aug 2007, Thomas Adam wrote:

Show 10 quoted lines

> 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"?

Ciao, Dscho