merge confusion

I had some unexpected behaviour doing a merge today. I wonder if anybody can tell me where I have gone wrong. This is the sequence...

* clone a remote repo
* created a local branch to track one of the remote branches
* did work on the local branch and then created another 'feature' branch from that
* time elapsed and at some point(s) I pulled from the remote but did not merge the original local branch
* finished feature, checkout local branch and merge in feature.

What I didn't expect is that all the subsequent changes on the tracked remote branch got merged in too. Which I didn't want.

So the question is - is that what's supposed to happen (ie. if you do any merge the tracked branch 'fast forwards' the remote) and, if so, if I want a branch that stays a branch (doesn't ever merge with the remote) how would I do that?

Thanks!

View this message in context: http://www.nabble.com/merge-confusion-tp24755682p24755682.html
Sent from the git mailing list archive at Nabble.com.

I think in this case you should do a git fetch instead. Doing a pull is the same as performing a fetch and merge.

With a fetch, your remote branch is up-to-date while your tracking branch is left untouched. You can later check the differences between the two branches and merge when you're ready.

$ git fetch # update remote branch heads
$ git diff origin/branchname # show what is different between your
local branch and the remote
$ git merge origin/branchname # only when you're ready

For me, it's easier to keep my personal branches separate by using a topic branch that doesn't track a remote branch. Then, optionally, merge in differences from whatever remote tracking branches as needed.

$ git branch -t development origin/development # tracking remote
development branch
$ git checkout -b mystuff development # my personal stuff

Now a git pull won't affect mystuff.

Allen

On Fri, 31 Jul 2009 06:41:32 -0700 (PDT) thepurpleblob <[email protected]> wrote:

Howard,

[...]

Not sure i'm following your question, will take a crack at it though. I believe this is what you did:

1. cloned a remote repo
2. created a local branch B and committed some changes onto it
3. created another local branch F
4. committed some changes on F
5. pulled in additional changes from a remote repo into F
6. committed additional local changes on F
7. merged F into B

When you merged the feature branch(F) you merged all the new commits made on it. By design this includes any commits you pulled in from any remote; you don't just get the subset of commits that you made locally.

There's nothing forcing you to merge with a remote, you just need to find a workflow that accomplishes what you want. As far as i can tell without knowing the actual commands you used, it appears you explicitly asked Git to merge in changes from the remote when you merged the feature branch.

So to hopefully answer your question, don't merge remote changes into your feature branch if you want your feature branch to only contain local changes when you merge it with other local branches.

HTH,
Sean

Did you 'git pull' or 'git fetch'? 'git pull' automatically merges, where 'git fetch' only gets the data.
You can just do a 'git branch branch-to-merge COMMIT' then 'git merge branch-to-merge' from your feature branch. Alternatively, you could just do a straight 'git merge COMMIT' from your feature branch. Though I'm not sure of the consequences of merging a commit instead of a branch.

Good luck,
Tim.

View this message in context: http://www.nabble.com/merge-confusion-tp24755682p26093419.html
Sent from the git mailing list archive at Nabble.com.

The only consequence is that the merge commit message (if there will be any, fast-forward merges don't merge anything) will mention the SHA1 instead of branch name. You can provide your own merge commit message, of course (while merging and afterwards).