Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> writes:
> On Thu, Oct 16, 2008 at 01:17:20PM +0100, Rick Moynihan <rick@xxxxxxxxxxxxxxxx> wrote:
>> I have a master branch, a dev branch and a number of feature branches from
>> dev. And I was wondering if there was an easy way to rebase dev and all of
>> it's sub-branches onto master.
>
> In general this is considered harmful. Why do you rebase your branch
> from time to time? For example in git.git, topic branches are based on
> master, then merged to master when they are ready, but they are never
> rebased.
I do not think it is harmful per-se as long as they are not published.
But rebasing topic branches regularly (i.e. without reasons better than
"the master has more commits than before") is _pointless_. The whole
point of a topic branch is to house the development related to one single
topic. If you keep rebasing it, its progress (when you look at the
differences between topic@{1} and topic, topic@{2} and topic@{1}, ...)
would not be about the single topic, but about the single topic _and
all the other random things that happened on the master branch_.
When you merge a topic branch that forked from an older version of
'master', you may have conflicts, and you may want to resolve it earlier
and that might be why you would want to rebase. But if you _know_ you are
going to have conflicts, you wouldn't wish to rebase all of them at once
to begin with, as you would need to resolve such conflicts yourself
anyway. On the other hand, if you expect there won't be any conflict,
then there absolutely is no point in rebasing them. If you want to make
sure that your topics would all work with the updated 'master', you are
much better off creating trial tree, merging your topics on top of the
updated 'master' one by one, than rebasing all of your topic branches.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
