Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 17, 2012, 22:12 UTC
- Message-ID
- <7vy5nl611n.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <7vmx427aj0.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 7 quoted lines
> Or are you only talking about the error exit from "git merge" that > would cause "git rebase -i" to stop and give control back to the end > user? > > I suspect that the latter behaviour to stop "rebase" in the middle > is in line with the spirit of --rerere-autoupdate, and it is not > likely that we would want to change it.
See this for the background:
http://thread.gmane.org/gmane.comp.version-control.git/85176/focus=85231
The entire thread (except for articles from a few uninformed noisemakers) is worth a read, as some issues that were discussed have resulted in more recent "rerere", and the original inquiry by Ingo illustrates the motivation behind them quite clearly.
And we can see that I was right when I wrote in the above that not committing is the right thing to do for --rerere-autoupdate / rerere.autoupdate even though I did not remember that thread. The second step described as "the way forward" in the quoted article hasn't happened yet.