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

Re: [BUG] git-rebase fails when a commit message contains a diff

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Nov 9, 2007, 14:19 UTC
Message-ID
<Pine.LNX.4.64.0711091418510.4362@racer.site>
In-Reply-To
<7v1wb0xhxq.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 8 Nov 2007, Junio C Hamano wrote:
Show 29 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Thu, 8 Nov 2007, Junio C Hamano wrote:
> >
> >> I wonder if this is a sensible thing to do, regardless of the issue 
> >> of commit log message that contains anything.
> >> 
> >> The patch replaces git-rebase with git-rebase--interactive.  The only 
> >> difference from the existing "git-rebase -i" is if the command is 
> >> called without "-i" the initial "here is the to-do list. please 
> >> rearrange the lines, modify 'pick' to 'edit' or whatever as 
> >> appropriate" step is done without letting the user edit the list.
> >
> > Hmm.  I don't know, really.  I had the impression that the "git 
> > format-patch | git am" pipeline would be faster.
> 
> Heh, I did not read rebase--interactive carefully enough.
> 
> Unless told to use merge with "rebase -m", rebase replays the change by 
> extracting and applying patches, and speed comparison was about that vs 
> merge based replaying; I thought make_patch was done in order to avoid 
> using cherry-pick (which is based on merge-recursive) and doing patch 
> application with three-way fallback.  Apparently that is not what 
> "interactive" does.
> 
> Perhaps pick_one () could be taught to perform the 3-way fallback dance 
> git-am plays correctly.  The patch I sent to make 
> git-rebase--interactive take over git-rebase would then become quite 
> reasonable, I would think.

I have a different idea: How about changing cherry-pick to try a simple patch first? If that fails, we can always go back to merge-recursive (or merge-nu once that is ready).

Ciao, Dscho

Previous: Junio C HamanoNext: Björn Steinbrink
Message 7 of 17 in “[BUG] git-rebase fails when a commit message contains a diff”
  1. Jonas FonsecaNov 9, 2007
  2. Junio C HamanoNov 9, 2007
  3. Junio C HamanoNov 9, 2007
  4. Junio C HamanoNov 9, 2007
  5. Johannes SchindelinNov 9, 2007
  6. Junio C HamanoNov 9, 2007
  7. Johannes SchindelinNov 9, 2007
  8. Björn SteinbrinkNov 11, 2007
  9. Benoit SigoureNov 9, 2007
  10. Johannes SixtNov 9, 2007
  11. Ralf WildenhuesNov 9, 2007
  12. Benoit SigoureNov 9, 2007
  13. Johannes SchindelinNov 9, 2007
  14. Andreas EricssonNov 9, 2007
  15. Steffen ProhaskaNov 9, 2007
  16. Johannes SchindelinNov 9, 2007
  17. Steffen ProhaskaNov 9, 2007

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.