linux-kernel - Re: Please pull ACPI updates

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:	Wed, 16 Jul 2008 19:56:44 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org
Subject: Re: Please pull ACPI updates

On Wed, 16 Jul 2008, Jesse Barnes wrote:
> 
> I'll dig around some more for git best practices too.  Based on what I've seen 
> of the x86 tree I don't have nearly enough branches

Don't worry about it. Start small. I think the x86 tree took up some 
pretty extreme limits, as can be seen by their 29-way merge or whatever it 
was. They also obviously have a lot more stuff going on than the PCI tree 
would be expected to have.

For most people, I'd expect that a small handful of branches is good. It 
might be just one, but it might be a couple of independent issues.

The point where a topic branch is _really_ useful is when you ask yourself 
whether that particular change is something that you (or somebody else!) 
might want to delay or test separately from some other change - that's 
when "oh, let's just use a separate branch for it" is really appropriate.

Len, for example, often did topic branches for individual bugzilla 
entries, and obviously for big conceptually separate things like ACPICA, 
which really _is_ a totally disjoint development track.

Other people, like rmk, use topic branches for particular hardware 
platforms.

On the other hand, if it's a trivial and obvious thing, there's no point 
in putting it into a separate branch. A number people who keep topic 
branches for all their major development then end up having a "misc" 
branch for just random things.

And remember: in git, topic branches are temporary things. You can rename 
them, you can delete them, you can ignore them. And before you've pushed 
things out, you can even decide to create a topic branch of a set of 
commits _after_ the fact. So you can commit _first_, and then decide that 
that commit was probably best to keep separate, so you create a topic 
branch with that commit on it, an go back to the pre-commit state on your 
regular branch.

BUT!

 - Not everybody _has_ to use topic branches. If you are maintaining 
   something that is very specific to begin with, _all_ your maintenance 
   is basically one topic to start with, so you'd never have separate 
   topic branches.

   The filesystem people, for example, do not tend to use topic branches 
   for this reason. They do their filesystem. They seldom have issues that 
   crop up on just certain platforms etc.

 - And more importantly - play around with it. Get used to it first. Look 
   at what other people do. Start small, with perhaps just one special 
   topic branch to test the waters with.

So don't worry _too_ much.

			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/