linux-kernel - Re: [GIT PULL 05/11] SoC-level changes for tegra and omap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Jan 2012 07:32:54 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Arnd Bergmann <arnd@...db.de>, Junio C Hamano <gitster@...ox.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org, Olof Johansson <olof@...om.net>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [GIT PULL 05/11] SoC-level changes for tegra and omap

On Thu, Jan 12, 2012 at 00:21, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, Jan 11, 2012 at 12:29 PM, Geert Uytterhoeven
> <geert@...ux-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@...ux-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/