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
| ||
|
Date: Sun, 24 Sep 2006 17:48:23 -0700 (PDT) From: Linus Torvalds <torvalds@...l.org> To: Sean <seanlkml@...patico.ca> cc: Russell King <rmk+lkml@....linux.org.uk>, Lennert Buytenhek <buytenh@...tstofly.org>, Dave Jones <davej@...hat.com>, David Miller <davem@...emloft.net>, jeff@...zik.org, davidsen@....com, alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org Subject: Re: 2.6.19 -mm merge plans 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 want. 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). 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/
Powered by blists - more mailing lists