linux-kernel - Re: 2.6.19 -mm merge plans

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-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0609241741210.3952@g5.osdl.org>
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/