I'd just like to add a link to a Git user who *doesn't* like rebasing: http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html
On 31 December 2012 07:26, Michael Richter <ttmrich...@gmail.com> wrote: > If I had written a ten-page post explaining in excruciating detail >> what rebase is, why it matters, and how to adapt it to the Fossil >> philosophy, who -but who!- would have read that first post? > > > I, for one, would have. I wouldn't necessarily have agreed, mind, because > the disagreement may be philosophical, not technical, but I appreciate > people putting in actual explanatory effort over "it's too much work". > > >> I was >> being (I thought!) considerate. And judging by last night's 30 posts, >> would it have made any difference to post a thesis-length argument for >> rebase? And if so, how was I to know that? Or should I have given up >> at the very first sign of trouble? > > > > I'm still baffled, frankly, as to why you don't just use the DSCM that > does what you want now instead of tilting at windmills with the one that > doesn't do what you want. > > The Erlang community faces this kind of problem on an almost monthly > basis. "I really like Erlang," it invariably starts, "but I don't like > immutable variables, and I want module-level mutable state, and I'd like to > be able to overload default function implementations with customized ones, > and I'd like a more imperative syntax, and…" > > In the end what they *really* want is Ruby (or Python (or C++ (or …))) > with one added feature from Erlang: easy concurrency. They don't > understand that the features of Erlang were set up the way they are for a > specific purpose, and a purpose that gets undermined when you remove those > features. The easy concurrency is the *least* important of the > architectural decisions that went into Erlang, it's just the most visible > of them. (Erlang isn't intended as a language for easily writing > concurrent systems. It's intended as a language for easily writing * > reliable* systems. The fabled "nine-nines".) > > You want rebase (or equivalent) because you want a clean history. I > appreciate Fossil *because* of the messy (where for me *s/messy/honest/*) > history. Because that messy history is a warning. It's a flag saying > "something went wrong here" that shows possibly complicated code issues or > problems in work flow or even problems with a developer's habits. If > understanding why something got that way is a problem, we enter with > another concept that's sadly all too lacking in software: we *document*it. > We explain it. We don't just brush it under the carpet and pretend it > didn't happen. > > > -- > "Perhaps people don't believe this, but throughout all of the discussions > of entering China our focus has really been what's best for the Chinese > people. It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
