Re: 2.6.19 -mm merge plans

From: Linus Torvalds
Date: Sun Sep 24 2006 - 20:49:45 EST

On Sun, 24 Sep 2006, Sean wrote:
> When Thomas makes a sweeping statement about the applicability of one
> tool over another people will respond to him. But if _you_ make such
> a statement yourself (even if it's based on his conclusions) then
> you better accept that people who disagree will respond to your statement.

I think it's unquestionable that sometimes it's better to work with
patches. The thing is, git by its very design is about tracking things
where history is firmly "set in stone", and that's not always what you

We've done a number of things to help people relax that a bit (notably
"git rebase" and "git cherry-pick"), and there are projects like stgit
that are more of a patch-management system on top of git, but even during
the early design phases I said that it's likely that git will be used in
_conjunction_ with tools like quilt etc, that are less strict than git is.

So I don't think we need to attack the notion of using non-git tools at
all. Especially if you don't know where you're going, git's very strict
immobile history can be a bit daunting.

(Of course, once you get really used to git, you use git _anyway_, and
then you use cherry-pick and other tools to re-write a cleaned-up version
of the thing that you originally screwed up because you didn't know what
you were doing. So you _can_ do this too with git, but that doesn't mean
that git would necessarily be the best way to do it).

That said, maybe we could help the "fixup" phases evenmore using git. For
example, right now you can do "git cherry-pick" to transfer individual
patches, but if you want to combine two commits while cherry-picking, it
immediately gets more involved (still quite doable: use cherry-pick
multiple times with the "-n" flag, but it's not as obvious any more).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at