On 12/30/2012 03:26 PM, Michael Richter 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. >
Except in the case where that messiness occurs in a private branch, and isn't ever pushed back to the central repository. Then the messiness is concealed. It sounds like Nico wants a better UI for managing private branches than a not-in-Fossil's-philosophy history-rewriting mechanism. Especially since, for a few days now, he's been talking about not rewriting history, but doing the rebase-like operations by always making new branches, and not interfering with the existing ones. If I've got this much right, what would that kind of UI look like? > -- > "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
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
