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    [W:0.023 / U:92.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site