A few minutes ago, Robby Findler wrote: > On Sun, Nov 11, 2012 at 11:55 AM, Eli Barzilay <e...@barzilay.org> wrote: > > Three hours ago, Robby Findler wrote: > >> If so, can we forbid them on the server? > > > > I hesitate to do that since there are some cases where a merge > > commit makes sense. > > So far, I've not seen the need. Can you say more about this?
When there's a large chunk of work over an extended period, it can be clearer to have a merge commit done so the history looks closer to how things happened. [Clarification for the curious: when you rebase your tree, the commits are recreated, with a new commit date, but the same author date. So you end up with commit dates that are chronological when you view the (linear) commit graph, but the actual dates are the author dates which are of course all messed up now. This is usually not a problem, but with a long-lived development it can be cleaner to preserve a more accurate picture of the history.] > Also, given how all of the ones we've had so far have been mistakes, > how about we forbid it and then, when necessary, unforbid, merge, > reforbid? Doing just that would be very awkward (you'll push, get rejected, try to figure if you did something wrong, mail me, I'll allow it and tell you, you'll re-push and tell me to re-forbid it). Another alternative is for me to have the ability to do that -- but I dislike this kind of magical power too. Can you see if this is a real problem with bisecting? (I've tried to read around, and it doesn't look like there should be problems with merges.) (Another sidenote: there are popular workflows that involve merges as the normal operation, so I'd expect bisecting to work fine with them, otherwise it would be a very known problem. In particular, merges are very strongly encouraged by a github-centric workflow.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________ Racket Developers list: http://lists.racket-lang.org/dev