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

Re: Heads up: major rebase -i -p rework coming up

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jan 25, 2009, 23:29 UTC
Message-ID
<alpine.DEB.1.00.0901260026310.14855@racer>
In-Reply-To
<200901252303.29204.jnareb@gmail.com>
Hi,
On Sun, 25 Jan 2009, Jakub Narebski wrote:
Show 20 quoted lines
> On Sun, 25 Jan 2009, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > So maybe I answered my question myself:
> > >
> > > 	merge parents $sha1 [$sha1...] original $sha1 $msg
> > 
> > When you are reparenting, how would original commit get in the 
> > picture? You wouldn't want the resulting merge to claim it merged X 
> > (which would be what's in original's commit log) when in fact it now 
> > merged Y because the user reparented it, would you?
> 
> Well, the subject part of merge (with merged branches names) shouldn't, 
> I guess, change. The summary (shortlog) part might, or perhaps even 
> should following rewrite (if it was present here).
> 
> But there is one issue I am wondering about: could we pick up _merge_ 
> _resolution_? So if you have evil merge, and the change is for example 
> splitting commits without visible final changes, or just changing some 
> commit message before merge, it would get recreated without problems?

Nanako had a script at some stage; I would prefer an subcommand to "git rerere" which reconstructs the whole merge in-memory, and then records the conflict's resolution.

However, I really think you are getting ahead of yourself. That is by no means something we want to have in rebase -p. And even then, it would have to be non-automatic, i.e the user has to check the resolution.

We _know_ that git rerere does a fine job most of the time, almost all of the exceptions to be found when working with rebase -i extensively, as you are prone to take different decisions during development.

Ciao, Dscho

Previous: Jakub NarebskiNext: Nanako Shiraishi
Message 18 of 27 in “Heads up: major rebase -i -p rework coming up”
  1. Johannes SchindelinJan 24, 2009
  2. Junio C HamanoJan 24, 2009
  3. Johannes SchindelinJan 24, 2009
  4. Johannes SchindelinJan 24, 2009
  5. Junio C HamanoJan 24, 2009
  6. Johannes SchindelinJan 25, 2009
  7. Marc BranchaudJan 26, 2009
  8. Thomas RastJan 24, 2009
  9. Johannes SchindelinJan 25, 2009
  10. Johannes SchindelinJan 25, 2009
  11. Jakub NarebskiJan 25, 2009
  12. Johannes SchindelinJan 25, 2009
  13. Sverre RabbelierJan 25, 2009
  14. Johannes SchindelinJan 25, 2009
  15. Junio C HamanoJan 25, 2009
  16. Johannes SchindelinJan 25, 2009
  17. Jakub NarebskiJan 25, 2009
  18. Johannes SchindelinJan 25, 2009
  19. Nanako ShiraishiFeb 3, 2009
  20. Johannes SchindelinFeb 3, 2009
  21. Jakub NarebskiJan 25, 2009
  22. Björn SteinbrinkJan 25, 2009
  23. Marc BranchaudJan 26, 2009
  24. Stephen HabermanJan 27, 2009
  25. Johannes SchindelinJan 27, 2009
  26. Nanako ShiraishiJan 27, 2009
  27. Stephen HabermanJan 27, 2009

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.