git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: "Marco Costalba" <mcostalba@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: qgit idea: interface for cherry-picking
Date: Mon, 03 Jul 2006 13:03:44 -0700	[thread overview]
Message-ID: <7vd5cmqwv3.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <e5bfff550607030418n6a46c0cdh1a95155e1feb4356@mail.gmail.com> (Marco Costalba's message of "Mon, 3 Jul 2006 13:18:46 +0200")

"Marco Costalba" <mcostalba@gmail.com> 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.

  reply	other threads:[~2006-07-03 20:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-02 19:01 qgit idea: interface for cherry-picking Jakub Narebski
2006-07-02 21:33 ` Marco Costalba
2006-07-02 21:46   ` Jakub Narebski
2006-07-02 22:04     ` Marco Costalba
2006-07-02 22:54       ` Jakub Narebski
2006-07-03  5:45         ` Marco Costalba
2006-07-03  6:42           ` Junio C Hamano
2006-07-03 11:18             ` Marco Costalba
2006-07-03 20:03               ` Junio C Hamano [this message]
2006-07-04  6:22                 ` Marco Costalba
2006-07-04  6:39                   ` Jakub Narebski
2006-07-04 11:58                     ` Marco Costalba
2006-07-04 13:29                       ` Jakub Narebski
2006-07-04 18:38                         ` Marco Costalba
2006-07-04  6:41                   ` Junio C Hamano
2006-07-04  7:02                     ` Jakub Narebski
2006-07-04 11:21                     ` Marco Costalba
2006-07-04 18:23                       ` Marco Costalba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vd5cmqwv3.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=mcostalba@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).