linux-kernel - Re: [GIT PULL] SLAB changes for v2.6.38

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 for Android: free password hash cracker in your pocket

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

Message-ID: <AANLkTiknwXJF+pLJFQPqa7XPywi=boz-H+_JLk-T+Zp8@mail.gmail.com>
Date:	Tue, 11 Jan 2011 08:13:09 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	cl@...ux-foundation.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [GIT PULL] SLAB changes for v2.6.38

On Tue, Jan 11, 2011 at 2:41 AM, Pekka Enberg <penberg@...nel.org> wrote:
>
> Is cherry pick still sane from maintainer workflow point of view?

Yes, if it's the occasional random thing that happens once or twice,
it's much easier than a separate branch and merging it into other
branches.

We have the exact same thing happen every once in a while simply
because two people apply the same emailed patch to their trees. You
end up with the same diff and the same message. Yeah, it's not called
a "cherry-pick" then, but there's really not any technical difference
apart from the commands to generate the "duplicate" commits.

It can become a problem if there's a _lot_ of it going on, though. It
can cause subsequent merge issues if there are other changes in the
same area, for example. And it can be a sign of some bad workflow.

You could also simply think of it in terms of "number of extra
commits". If you cherry-pick and it shows up as one extra commit,
that's still easier to understand and fewer overall commits than
having a separate branch with just one commit, and then two merge
commits - to merge that special branch into the two branches you care
about.

Using that rough guideline, if you have three or more of these, it
would actually be better to have them in one branch, and then merge
that stable branch twice - fewer extraneous commits (but that also
requires that you don't merge after each one.

That said, "number of commits" is not a really meaningful measure
either. I really tend to like how the ACPI tree does things, with
separate branches for separate bugzilla entries - with nice relevant
branch naming (bug number or description) - and then merging them. At
that point you may well have a branch with just a single commit in it,
but now the extra merge actually _adds_ information and the history
looks better for it.

So there are no hard rules. I personally use "gitk" after pulling, and
quite frankly, "clean history" is pretty damn obvious.

                                Linus
--
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/