From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: Patch (apply) vs. Pull Date: Wed, 22 Jun 2005 10:56:30 +0100 Message-ID: References: <1119308502.3926.18.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Darrin Thompson , Junio C Hamano , git@vger.kernel.org X-From: git-owner@vger.kernel.org Wed Jun 22 12:12:57 2005 Return-path: Received: from vger.kernel.org ([12.107.209.244]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dl2Dm-0006kN-U6 for gcvg-git@gmane.org; Wed, 22 Jun 2005 12:12:39 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262771AbVFVKGc (ORCPT ); Wed, 22 Jun 2005 06:06:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262911AbVFVKCb (ORCPT ); Wed, 22 Jun 2005 06:02:31 -0400 Received: from cam-admin0.cambridge.arm.com ([193.131.176.58]:47093 "EHLO cam-admin0.cambridge.arm.com") by vger.kernel.org with ESMTP id S262928AbVFVJ5d (ORCPT ); Wed, 22 Jun 2005 05:57:33 -0400 Received: from cam-mail2.cambridge.arm.com (cam-mail2.cambridge.arm.com [10.1.127.39]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id j5M9uN6i027537; Wed, 22 Jun 2005 10:56:24 +0100 (BST) Received: from ZIPPY.Emea.Arm.com (cam-exch1.emea.arm.com [10.1.255.57]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id KAA12037; Wed, 22 Jun 2005 10:56:46 +0100 (BST) Received: from localhost.localdomain ([10.1.69.144]) by ZIPPY.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 10:56:45 +0100 To: Daniel Barkalow In-Reply-To: (Daniel Barkalow's message of "Tue, 21 Jun 2005 14:02:05 -0400 (EDT)") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-OriginalArrivalTime: 22 Jun 2005 09:56:45.0345 (UTC) FILETIME=[B2D59110:01C57710] Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Daniel Barkalow wrote: > On Mon, 20 Jun 2005, Darrin Thompson wrote: >> Would it make sense to come up with a way to make an emailed series of >> patches represent a series of commits? Could patches still be >> cherrypicked? While you could cherry-pick a changeset generated by a commit (i.e. the diff between the commit's tree and its parent), I found this not to always be convenient. For example, a fix might need more than one commit but there is no way to know how they relate and which changesets to cherry-pick, unless somebody tells you exactly. > Commits are fundamentally resistant to cherrypicking, because they give > the state of the tree rather than expressing changes in that > state. Long-term, I think that something like StGIT should be integrated > into the system and deal with generating the HEAD you get after getting > patches in. With StGIT, you can gather many related commits into a patch. This patch (i.e. a series of related commits) could be pulled into your tree and pushed onto your stack of patches. StGIT should also allow one to upgrade the pulled patch and re-applied onto the stack. Thanks to Daniel's suggestion for multiple heads support, StGIT will (in a future release) support pulling changes from a remote tree together with the patch series information. After this is done, applying patches from different branch (head) would be quite simple. One problem is patch dependency tracking (i.e. you cannot push a patch onto the stack if it expects a certain patch to be already applied). Darcs does this by checking whether two patches can be commuted. I have to think a bit more about how StGIT could handle this. -- Catalin