From: Junio C Hamano Date: Tue, 14 Feb 2006 00:33:05 GMT Subject: Re: git-bisect problem Message-ID: <7v3bimzsn2.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20060213015146.26e6c09d.akpm@osdl.org> Andrew Morton writes: > git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all > > and that chewed 10 minutes CPU time and produced no output, so I killed it. A single commit is either: git format-patch -o ~/a 386093^ 386093 git show 386093 But if you _did_ want to get everything that builds on top of 386093 (and Linus counted 1000+ commits if I recall), format-patch could be optimized. It currently does a lot more than just format 1000+ commits, to handle case where "his" and "mine" are not linear history and may have the same change acquired by applying the same patch: 1---2---3 mine / ---4---5---6 his In this picture, it does not just format 1 2 3. It first checks 1 2 3 5 6, and if each of 1 2 3 introduces the same change as either 5 or 6 introduces to omit it from the output. If 2 and 5 are the same change from 1 and 4 respectively, the final result has 1 and 3. This is OK and useful for smaller branch, but clearly expensive for long branches. This is omitted when the ancestry graph would look like this: 1---2---3 mine / ---4 his but that would not have helped in this case anyway. Maybe we could have --no-omit-common flag or something to disable this check.