[racket-dev] merge commits and git bisect?

A few minutes ago, Robby Findler wrote:
> On Sun, Nov 11, 2012 at 11:55 AM, Eli Barzilay <eli at 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!