From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: qgit idea: interface for cherry-picking Date: Sun, 02 Jul 2006 23:42:22 -0700 Message-ID: <7vzmfrrxyp.fsf@assigned-by-dhcp.cox.net> References: 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 08:42:42 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 1FxI8j-0002jG-J1 for gcvg-git@gmane.org; Mon, 03 Jul 2006 08:42:38 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750812AbWGCGmY (ORCPT ); Mon, 3 Jul 2006 02:42:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750833AbWGCGmY (ORCPT ); Mon, 3 Jul 2006 02:42:24 -0400 Received: from fed1rmmtao09.cox.net ([68.230.241.30]:64959 "EHLO fed1rmmtao09.cox.net") by vger.kernel.org with ESMTP id S1750812AbWGCGmX (ORCPT ); Mon, 3 Jul 2006 02:42:23 -0400 Received: from assigned-by-dhcp.cox.net ([68.4.9.127]) by fed1rmmtao09.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060703064223.MGDH6385.fed1rmmtao09.cox.net@assigned-by-dhcp.cox.net>; Mon, 3 Jul 2006 02:42:23 -0400 To: "Marco Costalba" In-Reply-To: (Marco Costalba's message of "Mon, 3 Jul 2006 07:45:17 +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: > When I need to modify the patch/revision before to import I usaually > drag&drop and then I call git-reset --soft, then I edit working > directory and commit again. These days, I tend to just let "am" or "pull" do its thing, edit working tree and retest, and run "commit --amend". Before we added "commit --amend", I used to do soft reset and recommit like you described above. One advantage of "commit --amend" is that it can even amend a merge, but I do not think it applies to what Jakub wants in this thread. > Perhaps I can automate this in case the user answers "No, apply to > working dir only" to the message box. > > Is it the correct way to go or is better to wait for a --no-commit > flag in git-am? Probably your "git-am --no-commit" would stop after applying one patch (the first one in the sequence) but before writing a commit. We already sometimes do that when the patch does not apply cleanly, so I do not offhand have much objection against adding such a flag. I think the workflow to continue after "git-am --no-commit" will be quite similar to what you would do when "git-am --3way" stops with conflicts. In order to continue from there, you would do whatever is needed to bring the index into the shape you wanted to have if the patch applied cleanly. Then "git am --resolved". Perhaps something like the attached. If somebody finds it useful, after testing it out, please kick it back to me, perhaps with a paragraph or two to properly document it. -- >8 -- git-am --fail The new flag prevents a new commit from being made even when the patch applies cleanly. This gives you an opportunity to further fix up the change in your working tree before making the final commit. In order to continue, do whatever is needed to bring the index into the shape you wanted to have if the patch applied cleanly, and run "git am --resolved". Signed-off-by: Junio C Hamano --- diff --git a/git-am.sh b/git-am.sh index 679045a..77d8cd9 100755 --- a/git-am.sh +++ b/git-am.sh @@ -3,7 +3,7 @@ # # Copyright (c) 2005, 2006 Junio C Hamano USAGE='[--signoff] [--dotest=] [--utf8] [--binary] [--3way] - [--interactive] [--whitespace=