Re: Best practices for merging?

What if there were an official place to keep dirty histories? For example, my TypeInType patch has a very long, very tortuous history. Probably the majority of commits don't compile. (On a development branch meant for private use, I see no good reason to insist that each commit builds.) I would never want that history to join the main repo. But I've made sure that I keep access to it, just in case. It's all publicly available on github. The problem is that only I know where to find it. If we had an official "dump your dirty history here" repo, perhaps that would be helpful when disaster strikes. Richard On Feb 2, 2016, at 9:49 AM, Brandon Allbery wrote:

On Tue, Feb 2, 2016 at 9:23 AM, Alexander Berntsen wrote: On 02/02/16 15:20, Brandon Allbery wrote:

...

Only if it builds and passes tests across all ten commits. Yes, obviously. I have never worked anywhere where breaking commits were allowed, and I did not intend to suggest that breaking commits were a Good Idea or useful. They emphatically aren't.

The point is, this only applies once it's in the ghc repo. Works in progress may well have such commits as long as they are cleaned up on pushing --- which is why you would squash commits together losing intermediate history, which is what started this thread. (This point was actually made earlier in the thread, just not in so many words.)

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs