Re: merge into branch currently not active / checked out

Thomas Glanzmann [off-list ref] writes:

Hello,
is it possible to merge into a branch currently not active/checked out?
I have the following scenario:

        - One branch per feature (cstatus, headers, mutt-collapse-flags, small-fixes)
        - One upstream branch (master)
        - One branch that has every feature branch (tg)

(faui00u) [~/work/mutt/mutt] git branch
  cstatus
  headers
  master
  mutt-collapse-flags
  small-fixes
* tg

I want to merge master in every of the feature branches. Is that possible or
just bullshit because I don't have a working tree to handle conflicts?

Exactly.  Merge would want to have working tree, so merging into
the current branch is not just the default but the only mode of
operation.

In general, I would recommend against merging 'master' to topic
branches, if you can avoid it.

There are two reasons you would ever want to merge 'master' to
them.

 (1) You notice that 'master' has new stuff.  It does not
     necessarily conflict with the changes you made to your
     topic branches, and it often doesn't, if the project is
     well modularized.  Still, you want to make sure that your
     topic branches are compatible with it.  IOW to see if the
     changes in the master did not break your topic.

 (2) You notice that 'master' actually have new change that
     actively interact with what you set out to do in some of
     your toipcs.

If you plan to eventually ask somebody who integrates the
'master' to pull from you, and keep the resulting development
history clean, (1) is _NOT_ a good reason to merge 'master' into
your topics.  Because after your topic finally is finished, when
'master' pulls it, it will see many "senseless" merges from
itself.

Such "an integration testing" is better done, instead, by
forking a 'test' (perhaps throw-away) branch from 'master', and
merging all your topics into it.

On the other hand, (2) is a valid reason to resolve conflict
(both textual and semantic) early before you eventually present
your work for inclusion to 'master'.

Also, if you do not publish your work-in-progress topics, you
might want to consider rebasing on top of 'master', instead of
'merging'.  Rebase can take the topic branch name and switch
your current branch for you when you give it, like so:

	$ git rebase master topic1
        $ git rebase master topic2
        ...

Hi Junio,

If you plan to eventually ask somebody who integrates the 'master' to
pull from you, and keep the resulting development history clean, (1)
is _NOT_ a good reason to merge 'master' into your topics.  Because
after your topic finally is finished, when 'master' pulls it, it will
see many "senseless" merges from itself.

the problem is. Getting a patch into mutt takes several years. At least
it took for the hcache. So what I do is keep my patches up2date on top
of there HEAD. So I prefer topic branches. And my patches throw _once_
in 4 years a conflict that was not automatically resolved. I used
bitkeeper before, now I use git.

Such "an integration testing" is better done, instead, by forking a
'test' (perhaps throw-away) branch from 'master', and merging all your
topics into it.

I dislike it myself.

Also, if you do not publish your work-in-progress topics, you
might want to consider rebasing on top of 'master', instead of
'merging'.  Rebase can take the topic branch name and switch
your current branch for you when you give it, like so:

I don't push my work other than in patches that is, so I am going to
give it a try. I always wanted to try rebase, but I never actually did
try it.

Thanks,
        Thomas

On 2007-06-17 12:16:35 +0200, Thomas Glanzmann wrote:

the problem is. Getting a patch into mutt takes several years. At
least it took for the hcache. So what I do is keep my patches
up2date on top of there HEAD. So I prefer topic branches. And my
patches throw _once_ in 4 years a conflict that was not
automatically resolved. I used bitkeeper before, now I use git.

For this use case, I'd say rebasing is the right thing to do --
otherwise you accumulate a 4-year-long history of uninteresting
merges, as Junio warned.

There are two cases where rebasing is worse than a "real" branch
that's merged instead of rebased:

  1. Other people base their work on yours, and need to be able to
     pull. They want a stable foundation to build on, one that doesn't
     move.

  2. Your work is large enough that it's too much work to rebase it.
     (This also implies that when you merge, you get interesting
     conflicts, since for the case of autoresolved conflicts, rebasing
     isn't that much more expensive than merging.)

Since you describe your work as "a patch", I'm guessing neither excuse
applies to you. :-)

I don't push my work other than in patches that is, so I am going to
give it a try. I always wanted to try rebase, but I never actually
did try it.

<advertisement>
  You could also try StGIT. Rebasing a patch series on top of a git
  branch is what it does.
</advertisement>

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle