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

From: Thomas Adam <thomas.adam22@gmail.com>
Date: Aug 8, 2007, 21:56 UTC
Message-ID: <18071eea0708081456l2ff1b73dy90ef33c1b5058c77@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0708082246370.21857@racer.site>

On 08/08/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 20 quoted lines

> 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