Workflow question: A case for git-rebase?

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

Hi,

On Wed, 8 Aug 2007, Thomas Adam wrote:

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

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

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

On Wed, Aug 08, 2007 at 22:56:33 +0100, Thomas Adam wrote:

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.

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.