lkml.org 
[lkml]   [2012]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [GIT PULL 05/11] SoC-level changes for tegra and omap
From
On Thu, Jan 12, 2012 at 00:21, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Jan 11, 2012 at 12:29 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>>
>> And all of this would look nice if you would have done a rebase on top of the
>> latest tagged version of Linus' tree that contains all prerequisites, right?
>
> Rebasing means that nobody else can depend on or work with that tree,
> so it's a no-no.
>
> Sure, it works if you are the only person touching it, but then you
> had better not export it at all, so what's the point?

That's why you need two branches:
1. a non-rebasing one for development,
2. a rebasing one containing cherry-picked (possibly folded) commits for
preparing for upstream delivery.

Both branches contain an identical source tree at all times, but they contain
different commits. If you make a merge error in the first, or a rebase
error in the
second, you will notice as they will differ.
The non-rebasing branch should be used by your (sub)lieutenants to
base their work
on.
The rebasing branch is used for deliveries upstream. `for-next` and
`for-linus` are subsets of it. Patches emailed out for review
can/should come from this branch
(appying patches is also a form of rebasing).

> We have had independent problems in another branch exactly because it
> was rebased and people merged it, so bringing up rebasing as a
> "solution" is wrong-headed. It just causes *more* problems of other
> kinds, even if it may make git request-pull trivial.

Other people are supposed to merge the non-rebasing branch only. Just like
you (as in "everyone except Linus") only merge in your non-rebasing branch.

What I like (the most?) about git is that it tracks automatically what commits
in my rebasing branch have been applied upstream.

If you pull from your sub-lieutenants instead of applying patches, or if you
have multiple upstreams, it becomes more complicated, but I think git rebase
can still handle it.

Examples:
http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/master
(non-rebasing)
http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-queue
(rebasing)

Gr{oetje,eeting}s,
                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-01-12 07:35    [from the cache]
©2003-2011 Jasper Spaans