All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Yubin Ruan <ablacktshirt@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: git cherry-pick with --no-verify option
Date: Mon, 14 Mar 2022 23:13:16 +0000	[thread overview]
Message-ID: <xmqqee34m8kz.fsf@gitster.g> (raw)
In-Reply-To: CAJYFCiPw6VPPKpiC0f1iwdYf0LCFCbfrpNSHFs1qbwtGXX6pUA@mail.gmail.com

Yubin Ruan <ablacktshirt@gmail.com> writes:

> Is there any version of Git that supports the cherry-pick command with
> "--no-verify"?
>
> It is supported in "git commit" command but not in "git cherry-pick"
> command, and I always have to move .git/hooks/pre-commit away to work
> around this in case of "git cherry-pick".

Does "git cherry-pick" even trigger pre-commit hook in the first
place?  In my quick tests, it does not seem to.

 $ git init test
 $ cd test
 $ printf "%s\n" '#!/bin/sh' 'echo >&2 no' 'exit 1' >.git/hooks/pre-commit
 $ chmod +x .git/hooks/pre-commit
 $ git commit --allow-empty -m initial
 no

Up to this point, I set up a pre-commit that stops me
unconditionally and made sure it is working.

 $ git commit --no-verify --allow-empty -m initial
 [master (root-commit) 5d967c2] initial
 $ I=$(git rev-parse HEAD)
 $ echo "foo" >file
 $ git add file
 $ git commit --no-verify -m 'add file'
 [master 93a33c4] add file
  1 file changed, 1 insertion(+)
  create mode 100644 file

Then I built two commits

 $ git checkout --detach $I
 HEAD is now at 5d967c2 initial

And rewound to the initial commit so that the second one can be
cherry-picked on top of it.

 $ git cherry-pick master
 [detached HEAD 699c604] add file
  Date: Mon Mar 14 15:58:38 2022 -0700
  1 file changed, 1 insertion(+)
  create mode 100644 file

And that is understandable, as "cherry-pick" is more about replaying
what was committed in the past, with bugs and crufts preserved, than
committing a new-and-improved version out of an existing commit.

Perhaps in a case where a conflict stops the command there is
something?  Let's see.  Continuing from the above transcript:

 $ git cherry-pick master
 HEAD detached from 5d967c2
 You are currently cherry-picking commit 93a33c4.
   (all conflicts fixed: run "git cherry-pick --continue")
   (use "git cherry-pick --skip" to skip this patch)
   (use "git cherry-pick --abort" to cancel the cherry-pick operation)

 nothing to commit, working tree clean
 The previous cherry-pick is now empty, possibly due to conflict resolution.
 If you wish to commit it anyway, use:

     git commit --allow-empty

 Otherwise, please use 'git cherry-pick --skip'
 $ edit file
 $ git commit --allow-empty -a
 no

Of course, "git commit" to conclude a conflicted cherry-pick,
possibly with intervening conflict resolutin by editing working tree
files, would by default trigger pre-commit hook, and it of course
takes --no-verify as expected.

 $ git commit --allow-empty -a --no-verify --no-edit
 [detached HEAD 5858d22] add file
  Date: Mon Mar 14 15:58:38 2022 -0700

Ahh, I think the user is fooled by a bad advice in the message.
(all conflicts fixed: run "git cherry-pick --continue") is wrong and
misleading advice added by those who did not think things through.

After fixing all conflicts, run "git commit" to record it and then
you run "git cherry-pick --continue" if there are more steps to
cherry-pick (i.e. "git cherry-pick A..B").  "git commit" takes not
just "--no-verify" but other options like "--reset-author" to let
you take over authorship if the conflict resolution (actually,
adjusting the original commit to the different context it is being
cherry-picked to) is so involved that a change of authorship is
warranted.  "cherry-pick --continue" does not have all the necessary
flexibility and conceptually it is a separte operation (i.e. "please
continue the stopped sequence" is what it means) from concluding the
current step in the sequence.



  reply	other threads:[~2022-03-14 23:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14  5:41 git cherry-pick with --no-verify option Yubin Ruan
2022-03-14 23:13 ` Junio C Hamano [this message]
2022-03-15  2:29   ` Yubin Ruan

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=xmqqee34m8kz.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ablacktshirt@gmail.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.