I'm surprised no one has linked this all-clarifying blog post :)


On Fri, Jan 7, 2011 at 4:52 PM, Eli Barzilay <e...@barzilay.org> wrote:
> Two hours ago, John Clements wrote:
>> Taking a step back: is there really anything wrong with such
>> commits?
> What Robby and Vincent generalizes too -- merging can be confusing
> sometimes, either to the author or to the others; and there are a
> bunch of tools that become less useful if the history line is
> cluttered with merges (for example, the log graphs become much less
> useful).  OTOH, doing a rebase means that for most users you end up
> doing the same amount of work (a conflict to resolve will happen
> either way).
> You could argue that these tools are the blame -- they could just
> ignore these merges -- but there is no proper way to know when a merge
> commit was really trivial (the notifications script is guessing when
> it is, and I had a question on this on the git list, bottom line is
> that you can't tell without replaying the whole thing).  Bisecting is
> even more problematic, since it really wants a flat line to work on.
> --
>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                    http://barzilay.org/                   Maze is Life!
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
  For list-related administrative tasks:

Reply via email to