git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Does extending `--empty` to git-cherry-pick make sense?

From
Taylor Blau <me@ttaylorr.com>
Date
Jan 4, 2024, 19:33 UTC
Message-ID
<ZZcIG+mNXhZ0rHw3@nand.local>
In-Reply-To
<CAHPHrSevBdQF0BisR8VK=jM=wj1dTUYEVrv31gLerAzL9=Cd8Q@mail.gmail.com>
[+cc Elijah]
On Thu, Jan 04, 2024 at 12:57:18AM -0600, Brian Lyles wrote:
> Is there any real barrier to exposing that option to git-cherry-pick as
> well? Was this an oversight, or intentionally left out? The
> corresponding commit message doesn't seem to indicate any specific
> reason for limiting it to git-rebase.

I am not nearly as familiar with this code as Elijah is, but this certainly appears possible by setting the `drop_redundant_commits` and `keep_redundant_commits` flags in the replay_opts struct.

I don't see any fundamental reason why cherry-pick shouldn't have the same functionality.

Thanks, Taylor

Previous: Brian LylesNext: Elijah Newren
Message 2 of 4 in “Does extending `--empty` to git-cherry-pick make sense?”
  1. Brian LylesJan 4, 2024
  2. Taylor BlauJan 4, 2024
  3. Elijah NewrenJan 5, 2024
  4. Brian LylesJan 5, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.