Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> 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.

--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]