Hi, On Sun, 25 Jan 2009, Jakub Narebski wrote: > On Sun, 25 Jan 2009, Junio C Hamano wrote: > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
