Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Sun, 30 Dec 2012 01:24:44 -0600, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: snip Other things that can be redone in a rebase would include: From what you've said, I believe that it's these *other things* that you want: an easy way to munge commits as they get copied to a new branch. I don' think that's an unreasonable request, as opposed to wanting rebase. After all, we can do that now with repeated cherry-picking merges. But without a more detailed description than I want rebase, it's hard to tell if that's the case or not, propose alternatives, and otherwise engage in the process of refinement that peer review is supposed to provide. So perhaps all we need is a streamlined way to do multiple cherry-picks (which may even end up with a similar feel to git rebase --interactive). Whatever we do we can't call it rebase, because people will then assume that it is just like git rebase, and it won't be because it must not manipulate the pre-existing tree. If you don't believe that the name matters, just read the why does `fossil rm' not do the real thing? thread. Now for a few more general comments (30 messages overnight!!): Because upstream wants it is not necessarily a good reason. Upstream can be just as misguided as downstream. Also they should not be making requests that are difficult in their VCS of choice, and likely workflows should have been part of the process of choosing a VCS. That commits should do only one thing is a sensible idea (whether the one thing is a one line bug fix or a major feature implementation), but this is about project policy, and developers should work in such a way as to be able to achieve it. You can do it in Fossil, and if something you have to do to achieve it takes too long, then write, design, or ask for functionality to streamline it (in that order of preference!). One of the things that people seems to miss is that if you are working on several things in parallel (say a nearly finished feature, a feature in early exploration, and a few bugs some of which are on different branches) you should really be doing each in a separate working directory based on the same repository. This is easy in Fossil, and is possible in git (or even CVS!). You will of course have to do various merges, but everything will be fairly clean, and you won't even need stash! Upstream will always have to do some merges! Someone on every project should have a clear idea of how branches can and should be used, and write a branching policy. Being sensible about branches and merges covers many of the apparent problems. And finally, if you want something that Fossil can't do at all, even in a round-about or tedious way, you need to be able to express it in terms of development needs, not just as I want 'somevcs mangle'. Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Sun, Dec 30, 2012 at 7:58 AM, Eric e...@deptj.eu wrote: On Sun, 30 Dec 2012 01:24:44 -0600, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: snip Other things that can be redone in a rebase would include: From what you've said, I believe that it's these *other things* that you want: an easy way to munge commits as they get copied to a new branch. I don' think that's an unreasonable request, as opposed to wanting rebase. After all, we can do that now with repeated cherry-picking merges. But without a more detailed description than I want rebase, it's hard to tell if that's the case or not, propose alternatives, and otherwise engage in the process of refinement that peer review is supposed to provide. So perhaps all we need is a streamlined way to do multiple cherry-picks (which may even end up with a similar feel to git rebase --interactive). That's the essense of rebase. Glad we agree. Whatever we do we can't call it rebase, because people will then assume that it is just like git rebase, and it won't be because it must not manipulate the pre-existing tree. If you don't believe that the I repeat: git rebase does not manipulate the pre-existing tree, it does not destroy any history already in the tree. The only destructive action that git rebase does is change the commit that a branch _name_ points to, and from a fossil philosophy perspective this is the only aspect of git rebase that is worth differing on. name matters, just read the why does `fossil rm' not do the real thing? thread. Gratuitous terminology differences only burden users. Calling this something else will only placate the anti-git police. Now for a few more general comments (30 messages overnight!!): Depressing, I know. Because upstream wants it is not necessarily a good reason. Upstream can be just as misguided as downstream. Also they should not be making requests that are difficult in their VCS of choice, and likely workflows should have been part of the process of choosing a VCS. Sometimes you don't get to argue with upstream. It's either their way or the highway. But I've also explained in much detail why upstream actually *is* justified in asking for contributions to be nicely organized as a linear sequence of properly ordered commits that applies cleanly to the upstream trunk and where each commit stands alone, etcetera. As for making requests that are difficult in the VCS of their choice... I agree entirely. And that is why Fossil (as it is) cannot be considered for the large projects I've worked with. That commits should do only one thing is a sensible idea (whether the one thing is a one line bug fix or a major feature implementation), but this is about project policy, and developers should work in such a way as to be able to achieve it. You can do it in Fossil, and if something you have to do to achieve it takes too long, then write, design, or ask for functionality to streamline it (in that order of preference!). Agreed. I should show up with code in hand. I just did that for a different open source community (LyX), and I wish I could do it for this one. But I'm out of time for the next six months. What if I had intended response to that 3-paragraph initial post to help me gauge interest levels in a possible contribution of fossil rebase functionality? Why should I spend valuable time and effort on a contribution that will be rejected? The contribution I made to lyx-devel last week was one I weighed carefully through an earlier discussion on lyx-users. Your (that's general your) hospitality, or lack thereof, matters. This goes for me too: obviously I've allowed frustration to show, and this is bad since it only heightens hostility, and for this I'm sorry. One of the things that people seems to miss is that if you are working on several things in parallel (say a nearly finished feature, a feature in early exploration, and a few bugs some of which are on different branches) you should really be doing each in a separate working directory based on the same repository. This is easy in Fossil, and is possible in git (or even CVS!). You will of course have to do various merges, but everything will be fairly clean, and you won't even need stash! I never git stash -- it's a git feature I've yet to internalize (and you all thought I was a git zealot! ha). I generally commit everything, even work in progress, then switch to another branch, then back, and eventually I rebase to squash the work-in-progress commits if need be. Upstream will always have to do some merges! The upstreams I've worked with only ever accept merge-free (fast-forward, in git terms) commits. Occasionally one has such a large project to contribute that it's difficult to ensure that no other commits will slip in while one is updating the project to the trunk, in which case the upstream should lock the upstream so that no commits can be pushed until the project's
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Sun, Dec 30, 2012 at 02:05:38PM -0600, Nico Williams wrote: I repeat: git rebase does not manipulate the pre-existing tree, it does not destroy any history already in the tree. The only destructive action that git rebase does is change the commit that a branch _name_ points to, and from a fossil philosophy perspective this is the only aspect of git rebase that is worth differing on. git rebase is destructive due to a combination of not supporting more than one leave revision for a given named tag and dropping all other revisions on a non-fastforward push. Now a combination of recording what a rebase is based on and just marking the original commit as closed would pretty much serve the purpose of fossil. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
Nico Williams n...@cryptonector.com wrote: Go back through those 30 posts you mentioned. Go back to the very first one from me. I tried to be concise and wrote just three paragraphs that, IMO, captured what was needed. I certainly did not say I want git rebase in fossil and then watched the fireworks -- no, I explained *concisely* (or at least that was my aim). No, you said I want something slightly different than git rebase in fossil. Concise? Yes. Precise? No. Well-defined? No. Useful? No. 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 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? That depends on the goal. If you want to troll the list, then arguing for rebase is a good choice. If you want fossil to incorporate a solution for your problem, you should provide the information people are asking for. Given how poorly your attempt to work with the comunity has gone, giving up now isn't an unreasonable option. On the other hand, if you want to be able to use fossil, and are willing to work with us to solve your problem instead of arguing about what rebase does, you can start by answering our questions. For instance, you haven't answered any of my questions. You've explained in detail what rebase does, but that's irrelevant, because rebase is only an approximation to what you want, and you haven't explained how what you want is different in sufficient detail for us to figure out what that is. You haven't shown us why the existing solutions are to much work. You haven't said what kind of interface you want (otherr than interactive rebase, and you haven't said what that interface looks like!). You may think you have, but your opinion here doesn't matter: if we don't have a clear understanding of what you want, we don't have it, and the onus is on you to provide it. The best way to do that is by answering our questions. rebase is just a name. Forget it. Quit trying to convince us that rebase is compatible with fossil. Show us that *what you want* is compatible with fossil. Of course, that has to start with a *precise* description of what you want, in fossil terms, not in git terms. Give us an *example*. Simplify it as much as you can, but leave in all the features you want. Show us how you'd do it with fossil now. Show us the commands you would like to have (and call them TBD or some such), and how we would use them. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil sqlite3
Is there any way to execute SQL statements from the command line using fossil sqlite3? The docs for thishttp://www.fossil-scm.org/xfer/help?cmd=sqlite3are a bit skimpy (to say the least). Like what are the *?OPTIONS?* mentioned, precisely? What I'm specifically trying to accomplish is to extract the project ID from the repository in a script file. If there's another way to do this I'm happy to use that instead, of course. -- 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
Re: [fossil-users] fossil sqlite3
On 12/30/2012 10:43 PM, Michael Richter wrote: Is there any way to execute SQL statements from the command line using fossil sqlite3? The docs for this http://www.fossil-scm.org/xfer/help?cmd=sqlite3 are a bit skimpy (to say the least). Like what are the /?OPTIONS?/ mentioned, precisely? What I'm specifically trying to accomplish is to extract the project ID from the repository in a script file. If there's another way to do this I'm happy to use that instead, of course. I think fossil info will get what you're looking for. eg: $ ../fossil info -R ~/fossil/test.fossil project-name: unnamed project-code: 07660919180b651835b3a51776a58007ca9fb6f9 fossil info calls it project-code but it seems to be the same thing that fossil new and fossil clone call project-id. -- Edward ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
