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

Re: git rebase behaviour changed?

From
Junio C Hamano <junkio@cox.net>
Date
Jan 17, 2006, 08:56 UTC
Message-ID
<7vhd83b5ca.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<7vvewjb5xz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> You are right.  We will lose #1 and #2, (although the "already
> up to date" might catch some cases) and this _is_ dangerous.  I
> need to do something about this soon.

Actually, I think we are OK; I do not think we would lose any commits. git-format-patch (actually, git-cherry called from there) does the right thing. It does not use the merge base done in git-rebase in any way.

In any case, we _do_ need an explanation and error-out upon finding a merge, as we discussed. If somebody really wants to rebase a merge, he can do that by hand, as Mike easily demonstrated.

Previous: Junio C Hamano
Message 9 of 9 in “git rebase behaviour changed?”
  1. Mike McCormackJan 17, 2006
  2. Junio C HamanoJan 17, 2006
  3. Mike McCormackJan 17, 2006
  4. Junio C HamanoJan 17, 2006
  5. Martin LanghoffJan 17, 2006
  6. Junio C HamanoJan 17, 2006
  7. Martin LanghoffJan 17, 2006
  8. Junio C HamanoJan 17, 2006
  9. Junio C HamanoJan 17, 2006

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.