merge confusion

merge confusion

[thepurpleblob]

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.

Re: merge confusion

[Allen Johnson]

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, Jul 31, 2009 at 8:35 AM,
thepurpleblob<howardsmiller@googlemail.com> wrote:
>
> 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.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: merge confusion

[Sean Estabrooks]

On Fri, 31 Jul 2009 06:41:32 -0700 (PDT)
thepurpleblob <howardsmiller@googlemail.com> wrote:

Howard,

> 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...
[...]

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

> 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.

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.

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

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

Re: merge confusion

[Tim Mazid]

thepurpleblob wrote:
> 
> 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!
> 

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.

Re: merge confusion

[Alex Riesen]

On Wed, Oct 28, 2009 at 13:01, Tim Mazid <timmazid@hotmail.com> wrote:
> 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.

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).