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

Re: Interactive rebase: using "pick" for merge commits

From
SHStefan Haller <lists@haller-berlin.de>
Date
Feb 23, 2024, 20:59 UTC
Message-ID
<2739325d-93b1-445c-aac9-3e0ec54a27e4@haller-berlin.de>
In-Reply-To
<040f142c-7ee2-429e-88eb-d328b01a4b8c@gmail.com>
On 12.02.24 15:38, Phillip Wood wrote:
Show 24 quoted lines
> Hi Patrick and Stefan
> 
> On 12/02/2024 07:15, Patrick Steinhardt wrote:
>> On Sat, Feb 10, 2024 at 10:23:16AM +0100, Stefan Haller wrote:
>>> On 09.02.24 17:24, Phillip Wood wrote:
>>> Yes, I'm familiar with all this, but that's not what I mean. I don't
>>> want to maintain the topology here, and I'm also not suggesting that git
>>> itself generates such "pick" entries with -mX arguments (maybe I wasn't
>>> clear on that). What I want to do is to add such entries myself, as a
>>> user, resulting in the equivalent of doing a "break" at that point in
>>> the rebase and doing a "git cherry-pick -mX <hash-of-merge-commit>"
>>> manually.
>>
>> It would be neat indeed if this could be specified in the instruction
>> sheet. We already support options for the "merge" instruction, so
>> extending "pick" to support options isn't that far-fetched. Then it
>> would become possible to say "pick -m1 fa1afe1".
> 
> It would certainly be possible to extend the sequencer to do that but
> I'm not familiar with why people use "git cherry-pick -m" [1] so I'm
> wondering what this would be used for. It would involve a bit of extra
> complexity so I think we'd want a compelling reason as to why
> cherry-picking merges without maintaining the topology is useful
> especially as one can currently do that via "exec git cherry-pick -m ..."

Ok, I suppose the answer will probably not count as a compelling reason. My reason for wanting this is that lazygit currently implements cherry-picking in terms of an interactive rebase, rather then calling git-cherry-pick. And the reason why it does this is that when you cherry-pick multiple commits, and one of them conflicts, then you get lazygit's nice visualization of the rebase todo list to show you where in the sequence you are, what the conflicting commit is, how many are left etc. It just happens to support this well for .git/rebase-merge/git-rebase-todo, but not for .git/sequencer/todo.

It probably makes more sense to teach lazygit to visualize the .git/sequencer/todo file, and then use git cherry-pick.

See https://github.com/jesseduffield/lazygit/issues/3317
-Stefan
Previous: Phillip WoodNext: Phillip Wood
Message 6 of 10 in “Interactive rebase: using "pick" for merge commits”
  1. Stefan HallerFeb 9, 2024
  2. Phillip WoodFeb 9, 2024
  3. Stefan HallerFeb 10, 2024
  4. Patrick SteinhardtFeb 12, 2024
  5. Phillip WoodFeb 12, 2024
  6. Stefan HallerFeb 23, 2024
  7. Phillip WoodFeb 26, 2024
  8. Stefan HallerFeb 26, 2024
  9. phillip.wood123@gmail.comFeb 27, 2024
  10. Junio C HamanoFeb 12, 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.