From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: qgit idea: interface for cherry-picking Date: Mon, 03 Jul 2006 13:03:44 -0700 Message-ID: <7vd5cmqwv3.fsf@assigned-by-dhcp.cox.net> References: <7vzmfrrxyp.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: git@vger.kernel.org X-From: git-owner@vger.kernel.org Mon Jul 03 22:03:53 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FxUe6-0008AW-1e for gcvg-git@gmane.org; Mon, 03 Jul 2006 22:03:50 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750972AbWGCUDr (ORCPT ); Mon, 3 Jul 2006 16:03:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751276AbWGCUDr (ORCPT ); Mon, 3 Jul 2006 16:03:47 -0400 Received: from fed1rmmtao01.cox.net ([68.230.241.38]:50823 "EHLO fed1rmmtao01.cox.net") by vger.kernel.org with ESMTP id S1750972AbWGCUDq (ORCPT ); Mon, 3 Jul 2006 16:03:46 -0400 Received: from assigned-by-dhcp.cox.net ([68.4.9.127]) by fed1rmmtao01.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060703200345.QLOJ22974.fed1rmmtao01.cox.net@assigned-by-dhcp.cox.net>; Mon, 3 Jul 2006 16:03:45 -0400 To: "Marco Costalba" In-Reply-To: (Marco Costalba's message of "Mon, 3 Jul 2006 13:18:46 +0200") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: "Marco Costalba" writes: > I cannot test your patch now, so I'm just guessing, what if we have a > series of patches? The patch stops at each patch. I am primarily interested in keeping "git-am" usable from command line while making it easy to use from other tools. The expected use for the patch you are responding to is that after the first application with --fail the user has an opportunity to fix the result up but needs to create a commit by rerunning "git-am" (or just drop that by resetting the index and saying "git-am --skip"). > Is it possible that for two patches A and B happens that > > git-am A > git-am B > git-reset --soft HEAD^^ > > gives a different result then > > git-am --fail A > git-am --fail B If you had a series of patches chosen inside your GUI and squash-apply them all, two full am with soft reset to the original state would be the easiest, if and only if both patch applications do not fail. If patch A does not apply for whatever reason, you have to guide your user through the patch adjustment process before applying B, regardless of the reason why the patch application failed (either A did not apply cleanly, or you gave --fail to the command). The main question is what you would let your users do and how you would guide them through the process, when the application of an earlier patch in the series fails. I think it is a secondary implementation detail which of "git-am", "git-am --fail" or "git-apply" to implement that process.