Best practices for merging?

Richard Eisenberg eir at cis.upenn.edu
Tue Feb 2 14:55:03 UTC 2016


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 <allbery.b at gmail.com> wrote:

> 
> On Tue, Feb 2, 2016 at 9:23 AM, Alexander Berntsen <alexander at plaimi.net> 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 at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160202/e50a42be/attachment.html>


More information about the ghc-devs mailing list