2008/7/29 Jeff King <peff@xxxxxxxx>: > On Mon, Jul 28, 2008 at 05:37:33PM -0700, Junio C Hamano wrote: > > I just didn't want history thrown away for two reasons: > > - historical interest; some of the commits had counterparts in devel > that were done differently (because the two branches had diverged), > but it might later be interesting to see how and why the stable > changes were done (e.g., if a similar situation arose) > > - this project did not rebase, favoring the simplicity of "git pull" > over clean history. > > Bear in mind that this project was not very big. I think devel had ~20 > commits, and stable had about ~5. So it was easy to get such confidence. Is there any reason you couldn't have reverted the stable commits in preparation for the merge from devel? I.e. these commits were necessary to fix problems in production, they now need to be reverted in order to cleanly apply the changes for the next stable version, which includes fixes for all of these problems. I can see you'd be preserving twice as much history instead of throwing any away, but if scalability became an issue, you could always squash all the reverts into one pre-merge commit. git-merge-theirs-revert anyone? Mike -- 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
