Re: [PATCH] commit: correct advice about aborting a cherry-pick

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King wrote:
> Hmm. I don't think I've run across this message myself, so perhaps I do
> not understand the situation.

It's very simple.

  # on branch master
  $ git checkout -b test
  $ git cherry-pick master
  $ ls .git/sequencer
  # missing

In the pseudo multi-pick case (I say "pseudo" because there's really
just one commit to pick):

  # on branch master
  $ git checkout -b test
  $ git cherry-pick master~..
  $ ls .git/sequencer

cat .git/sequencer/todo if you like.

>   2. Skip this commit and continue the rest of the cherry-pick sequence.

Nope, this is unsupported afaik.

> Those are the options presented when rebase runs into an empty commit,
> where (2) is presented as "rebase --skip". I'm not sure how to do that
> here; is it just "cherry-pick --continue"?

No, --continue will just print the same message over and over again.

Yes, the whole ranged cherry-pick thing can use a lot more polish.

>   1. What happened (the cherry-pick is empty).
>
>   2. How to proceed from here (allow-empty, abort, etc).
>
> You still want to say (1), but (2) is useless to old-timers.  Probably
> something like advice.cherryPickInstructions would be a good name for an
> option to squelch (2), and it should apply wherever we tell the user how
> to proceed. Potentially it should even be advice.sequenceInstructions,
> and apply to rebase and am as well.

Good suggestion.  I'll pick advice.cherryPickInstructions when I
decide to polish sequencer.c a bit.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]