From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Please pull ACPI updates
Date: Thu, 17 Jul 2008 02:57:29 UTC
Message-ID: <fa.aQ2TNllwOA2xov1BBNDF9/oFaWU@ifi.uio.no>

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Please pull ACPI updates
Date: Thu, 17 Jul 2008 15:48:12 UTC
Message-ID: <fa.oJwLDCdDLlBB10m1Ah5px2T9688@ifi.uio.no>

On Thu, 17 Jul 2008, Linus Torvalds wrote:
>
> That's the whole point of topic branches. They allow you to separate out
> work to different areas, so that people who are interested in (say) the
> PCI-impacting ones can merge with one part, without having to wait for the
> other parts to stabilize.

Btw, you don't really have to have a lot of them.

When it comes to ACPI in particular, I would really prefer to see at least
the ACPICA stuff in a separate topic branch. It comes in from a different
source, it's maintained separately, and when it causes problems(*) it ends
up usually being handled differently too.

Len additionally split things like bugzilla entries up into individual
topics, and that was really nice to see when merging, but I have to say
that it was also "above and beyond" what I've ever expected of any
maintainer. That said, I think ACPI has been rather bugzilla-driven (many
other areas are feature-driven), and I do think it makes tons of sense to
put fixes in different branches, and then you can merge them when you
actualyl close the bug when the fix has been verified.

So one reason I reacted strongly to the ACPI change was definitely just
that ACPI used to be one of the really nicely done subsystems (not just
from a git standpoint, but the whole git flow was part of it). There were
some issues very early on in git usage, but I gave a shout-out to Len at
the last kernel summit for a reason.

And in that sense it's definitely unfair to require quite _that_ level of
separation. I'm really not expecting it.

But I *really* hate pulling from somebody, and seeing commit dates that
are from five minutes ago, and based on something that I had just pushed
out (which was essentially the case for this round of ACPI changes).

That literally shows that the code was hardly tested _at_all_ in that
exact configuration. It may have gotten testing based on some earlier
kernel version, but then it very clearly got rebased (or just quilt
imported) on top of a totally new kernel base, and was not tested in that
version very much if at all.

So even if you end up using quilt, I'd suggest you do so on a specific
base, rather than on some random "kernel-of-the-moment-in-the-middle-
of-the-merge-window". Because then at least I feel like the people
involved have been doing their own development without having the rug
pulled out from them all the time by using a different kernel as a base.

		Linus

(*) Which is happily fairly rare these days! I obviously detest the
complexity that is ACPI, but even if I detest it, Intel should get cudos
for getting it to work.

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Please pull ACPI updates
Date: Thu, 17 Jul 2008 16:03:23 UTC
Message-ID: <fa.ol0SiKyzOm1vtMLNL5jXw8FhfkE@ifi.uio.no>

On Thu, 17 Jul 2008, Linus Torvalds wrote:
>
> But I *really* hate pulling from somebody, and seeing commit dates that
> are from five minutes ago, and based on something that I had just pushed
> out (which was essentially the case for this round of ACPI changes).

And Andi, before this goes any further, I'd like to say that (a) no, I
don't hate you and (b) sorry in advance and in retrospect for my obviously
abrasive personality and just being harsh.

In particular, this is something that I have gone through with a _lot_ of
maintainers. So you don't need to feel bad about it. Ingo and Thomas
obviously did the very same thing not that long ago.

And Davem had the same issue in the networking tree - most of the times
when I pulled, I could tell that he had _just_ rebased the whole series,
and I just knew that it had gotten effectively zero testing in that
particular configuration.

For other trees it's still ongoing: you can generally trivially tell by
looking at the merges and the dates of the commits relative to them and
'base' they are done on top of.

So you're definitely not alone. There are people who have done the same
thing, and in many cases they did it for months. I'll happily try to help
you with any git issues, and we can even change git itself to help with
some things (historically we certainly have - I certainly hope that the
need for it is going away, though).

And I can also report that the people who then re-learnt their workflow
and got used to maintaining several queues and not always working at the
top of the tree and rebasing on top of whatever "random Linus kernel of
the moment" (in order to actually work with and test what they eventually
ask me to pull!) have so far been pretty enthusiastic about the workflow
they learn once they pick it up.

And to give them credit for being smarter them me, others (like Jeff)
started doing the whole "many different branches" thing long before I
personally even realized how helpful it is.

And as mentioned, some still use the "queue on top of the most recent
version" model, and when it's something fairly far away in the periphery
and doesn't impact others, I don't really care. If it hadn't been for the
PCI merge bringing up the issue, I'd have ignored the ACPI case too.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [git pull] x86 updates for v2.6.28, phase #2 - PAT updates
Date: Fri, 10 Oct 2008 17:24:27 UTC
Message-ID: <fa.c7XLU86/dQp9Nz4B6zIAGST5gRA@ifi.uio.no>

On Fri, 10 Oct 2008, Ingo Molnar wrote:

> Correction: i did the reverts shortly before applying the v2 series - so
> it was fully technical. I wanted to do a line by line review of the fix
> (and did it), because the lockup took quite some time to pin down. To
> avoid this mistake i could also have hard-reset the full v1 series and
> could have redone the whole topic.
>
> What's the best Git way to avoid such mishaps? I try to avoid resets and
> rebases of already pushed out bits as much as possible, because that is
> both risky because information can be lost and asocial because ongoing
> work of contributors can be disturbed.

There's a couple of things you could have done.

The simplest approach is to kill the branch. Of course, you could do that
with just a "git reset", but if you had already pushed the branch out and
it wasn't one of the "gets rebased" branches, that's not very nice either.

But rather than doing "git reset" on an old branch, what I think is nicer
is to just create a new branch instead, and call it "PAT-v2" or something
like that - leaving the old one around, but simply never _using_ it for
anything (and obviously not merging it). That seems to match how you work
otherwise.

Just opening another branch has the advantage that it also allows you to
easily do cross-branch compares. It's actually how I work a lot personally
when I work with the git repo and do some new thing: I start a topic
branch for it, but it's inevitably going to be ugly in the end because I'm
finding problems as I go, so I just start another branch and basically
re-create a cleaner version in that.

(I don't end up merging with Junio with git - I just send him patches, so
all those branches end up being just private things, but it doesn't change
the basic workflow).

And the nice thing with starting a new branch is that you can do your
cleanups etc in it, and then things like

	git diff broken..new-branch

work fine to check the differences _between_ branches. In other words,
this is also a good way to just take a "v2" of a patch-series, and then
you basically get a inter-patch-series diff for free that shows what the
differences were.

Of cource, once you do that, you can also decide that you're not actually
going to use the new branch, you're just going to append the fixes from v2
to the old branch instead. So you may decide that your new branch (that
you never pushed out) is not worth making a new branch for, and that it's
actually going to be easier for people involved if you just turn the
second patch-series into a single (or multiple, for that matter)
fix-commit on top of the old patch-series.

Finally, one option that I do not recommend in this case (simply because
all of the commits got rewritten) is to actually keep both branches, but
do a merge between them and just pick the correct end result in the merge.
That can be useful as a way to show both histories, but I'd generally
suggest that only if there is some big reason why you'd really want to
have both sets of patches around later.

A reason for the last case could be two different approaches that were
both valid, and actually ended up both with a very similar end result, and
where the way they got to it was interesting and/or relevant exactly
because they were different. Or even if they weren't that technically
different, maybe they were done by different people, and keeping both ends
up showing the real development history _and_ gives credit to both.

There are other ways to do this too, but they all boil down to the "make a
new branch that starts at the common point". For example, instead of
creating a diff with "git diff broken..fixed" (whether to just see what
the breakage was, or to actually fix up the broken branch with), if the
series are very similar in structure and in many of the sub-commits, you
can end up using "git rebase" to rebase the fixed sequence on top of the
broken branch.

That last "git rebase" approach will generally cause a lot of conflicts
that you have to fix up by hand (since by definition the two branches will
obviously be touching the same area, and in slightly different ways), but
sometimes that can actually be exactly what you _want_, since the merge
conflicts are going to be exactly the things that changed, and if the
series was clean and didn't have lots of patches where one patch in the
series changed something that an earlier patch already modified, then the
rebase can be a nice way to get the incremental fixes on top of the old
broken branch from the fixed one.

So there are certainly different things you can do.

			Linus