Re: Heads up: major rebase -i -p rework coming up
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Jan 25, 2009, 22:03 UTC
- Message-ID
- <200901252303.29204.jnareb@gmail.com>
- In-Reply-To
- <7vwscjceec.fsf@gitster.siamese.dyndns.org>
On Sun, 25 Jan 2009, Junio C Hamano wrote:
Show 10 quoted lines
> 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?
-- Jakub Narebski Poland