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

["Thomas Adam" <thomas.adam22@gmail.com>]

On 08/08/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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