I'm surprised no one has linked this all-clarifying blog post :) http://tartley.com/?p=1267
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: http://lists.racket-lang.org/listinfo/dev
