Workflow question: A case for git-rebase?

Workflow question: A case for git-rebase?

[Thomas Adam]

Hello all,

So we've (as in my place of work) have switched from SVN to GIT
although I do have a few questions -- hopefully they're not too
obvious.  :)

We have our master branch which is where all the latest changes are
added to as a "remote shared repository which everyone pushes and
pulls to.   That's emulating pretty much what SVN did -- which is
fine.

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.  Luckily I
don't commit that since I do a git-diff beforehand.   :)

One suggest solution to this is to merge master into branchX/branchY
periodically, although this has the same problems as described when I
try to merge -- if I'm going to make branchX the same as master, I
might as well just work in master and be done with it, right?

So I was wondering if it's fine to branch from master at any given
point and perhaps use git-rebasse when I come to merge?  Is this even
the correct mode of working?  Indeed, there might be times when
git-rebase isn't necessary if a merge to master from branchX or
branchY won't revert a commit in master because that file had been
edited, so how do I determine when to use git-rebase in this case?  Or
is that the correct indicator?

I do hope that makes sense.

Kindly,

Thomas Adam

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

[Johannes Schindelin]

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

Ciao,
Dscho

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

[Thomas Adam]

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

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

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 3834 bytes --]

On Wed, Aug 08, 2007 at 22:56:33 +0100, Thomas Adam wrote:
> 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.

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@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]