On Tue, 2016-03-08 at 09:30 -0800, Jordan Justen wrote: > It sounds like the issue was a lack or gap in testing after the > rebase. > > I don't see that possibility going away just because you instead used > merge. Especially if you consider resolving merge conflicts or other > subtle errors that can creep in during a merge. (3a01358bdb03)
Right. The possibility of error doesn't go away. But the point is that the history is preserved, and you can work out what happened. Instead of ending up with a series of commits that apparently *never* worked. > I've worked on projects that generally rebase, and still regularly > have patchsets larger than 50 patches contributed. I've worked on projects that don't use version control at all. Or which use SVN. That doesn't make it a good idea. > EDK II has been forced to live in the rebase mindset for years due to > svn, and rebasing has not been a problem for us either. The point in moving to git was to make things better. :) > At the subsystem level, I think even the kernel often relies on rebase > along with format-patch/am to bring in patches rather than merges. As I said, don't let that get close to Linus or he'll eat you. > So I disagree with the statement that rebase should *NEVER* be used. > > For EDK II, we decided to start with a rebase model as it was a > smaller step (conceptually) from svn. I'm not sure what happened in > your rebase, but I think issues with this model will be no more > frequent than issues with merges. > > I don't think anyone has ruled out considering using merges once > everyone is more comfortable with git. Shouldn't we just switch to a proper usage model in one hit instead of prolonging the pain? That means fixing the CRLF thing ASAP too. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
