Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2013 05:12 PM, Richard Hipp wrote: Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. Yep; that hides all the private branch history into the private repo, though - what I'm talking about *looks* like that but has the history available to everyone if you expand the commit by clicking on a [+] in the web UI or some such. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDqsj8ACgkQRgz/WHNxCGo76ACdF0rjW4NqXpNFSR8Z4gdItTHF m/MAn2nj/pIFIXaAuSYbL5m+DHO2LpSs =bGDp -END PGP SIGNATURE- ___ 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 Mon, Jan 7, 2013 at 4:32 AM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2013 05:12 PM, Richard Hipp wrote: Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. Yep; that hides all the private branch history into the private repo, though - what I'm talking about *looks* like that but has the history available to everyone if you expand the commit by clicking on a [+] in the web UI or some such. This is exactly what I would like to see. Literally a mechanism to mark branches hidden where the markers are propagated on sync is all it would take. A .fossil-settings/hidden-branches file might be a good way to achieve this. from my previous post I could do my messy work on a branch that I will later hide and when happy with the result merge to a branch that I would keep visible. This keeps history intact but makes a nice uncluttered clean view available that captures only the important aspects of development and hides the noise. = ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDqsj8ACgkQRgz/WHNxCGo76ACdF0rjW4NqXpNFSR8Z4gdItTHF m/MAn2nj/pIFIXaAuSYbL5m+DHO2LpSs =bGDp -END PGP SIGNATURE- ___ 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.?
Hi! On Sat, Dec 29, 2012 at 11:56 PM, Nico Williams wrote: I happen to think that Fossil has a superior architecture and design. I'd like to use Fossil, but I can't, and I've explained why. I've also explained why I'm unlikely to be the only user who needs this one feature. Thank you Nico for thorough explanations about the benefits of a rebase-like feature and how it could grow our userbase. I hope there will one day be a rebase-like feature in Fossil, in line with the superb Fossil philosophy. Thank you Nico for your interest and energy to make Fossil better and more widely appealing. Best regards, M ;-) -- Marc Laporte http://MarcLaporte.com http://Tiki.org/MarcLaporte http://AvanTech.net http://svg-edit.googlecode.com http://jquerysheet.googlecode.com http://sourceforge.net/p/jcapture-applet/ On Mon, Dec 31, 2012 at 6:02 PM, Nico Williams n...@cryptonector.com wrote: Thanks Mike, I appreciate this. BTW, I now have a pretty good idea of what fossil rebase would look like; the discussion was a success, largely thanks to Joerg's insight. I've also started looking at src/merge.c to have an idea of how to implement a version of fossil merge --cherrypick that doesn't commit the merged changes (this being necessary to implement the interactive rebase edit-a-commit option, as well as for squashing) -- this is the essential ingredient, after all, and it seems like all that has to happen is we need an option to not update any non-temp tables in merge_cmd(). I think that will be a trivial change, actually, as it'd be a small modification to the fossil merge --nochange logic. I'll stop here. In six months I may have time to actually implement, and in the meantime I'll sketch an implementation. Happy New Year! ___ 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.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2012 09:33 AM, Nico Williams wrote: I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). That reminds me of a discussion I had with a dyed-in-the-wool git fan, of the make the history beautiful camp, who was a fan of making lots of tiny commits during development but then squashing them into a single neat patch to go onto the trunk. I was nervous about the history-loss this created, and one idea that I suggested as a compromise between our positions was a special kind of merge commit in the history that looked like a single commit containing the entire branch as a single patch in the UI, rather than like a merge of the topic branch containing the work. This would appear like rebasing the topic branch and squashing all the commits, but was actually just a merge in all respects other than how it looked in the timeline. Might that be a useful approach for Fossil, too? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDluxYACgkQRgz/WHNxCGp4HQCghgq9q1JuvzndW3tlkj0zXNS1 2XsAn0GS6hdXXtvj0C7aXBWvoDYDidjL =S55G -END PGP SIGNATURE- ___ 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 Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2012 09:33 AM, Nico Williams wrote: I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). That reminds me of a discussion I had with a dyed-in-the-wool git fan, of the make the history beautiful camp, who was a fan of making lots of tiny commits during development but then squashing them into a single neat patch to go onto the trunk. I was nervous about the history-loss this created, and one idea that I suggested as a compromise between our positions was a special kind of merge commit in the history that looked like a single commit containing the entire branch as a single patch in the UI, rather than like a merge of the topic branch containing the work. This would appear like rebasing the topic branch and squashing all the commits, but was actually just a merge in all respects other than how it looked in the timeline. Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDluxYACgkQRgz/WHNxCGp4HQCghgq9q1JuvzndW3tlkj0zXNS1 2XsAn0GS6hdXXtvj0C7aXBWvoDYDidjL =S55G -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ 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.?
Hello, In my opinion, the private branch concept only works well for people working in just one computer. In the every day more common case of people developing in several computers (desktop, laptop, tablet, etc), private branches do not adapt well to the situation. Probably the solution could be the combination of two concepts that have already been discussed in the past: 1- Selective sync of some branches depending on the remote repository 2- Mark some commits as hidden and do not show them in a normal timeline RR 2013/1/3 Richard Hipp d...@sqlite.org: If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change ___ 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.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Jan 2013 12:12:53 -0500 Richard Hipp drh-czdrofg0bjidnm+yrof...@public.gmane.org wrote: If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. That's fine, Richard, but we need ability to select single private branches while pushing as well as getting rid of them. Sincerely, Gour - -- For him who has conquered the mind, the mind is the best of friends; but for one who has failed to do so, his mind will remain the greatest enemy. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQ5eM2AAoJELhxXPVStcgQ4QoQAJO8eMu4x+O0Ay0tALlFIDnJ 3ruiL8W5qjuN4ZpaTdTjFJ7Hb0aoupXT0w6UwDtdFl7ui0ELQnz1+yZd6RnKXBLH wHhaxAbS5oJVz6lD8sJgATEYFAP/F9ojUA2Wb/Jf0CVTSIWkLee754kxROpBOFJB YnLhqIYDVG8LSSR6hIp31LYUdFok1Y+Rk5waGzHCx2zcwPx3ynLRc+0lRNxTHGYS wt3hO9zKAeuzrB+JeCYPrGMgYeuUGrYPqCIoPCcVZs0JaX4xjxlhLluS2x/RGyHC r/5zW3pHkw0nJUOjZ0kfu+p8iRCbtY8pWpkZjVeNma2hdnAVyWNBCcfuRq3gLCVU N7PjBtUP4+pGQHbUw5ivLBfnEsfLQ9feU1zTCzRI411FcjWCE+pMwTVF8WilMDhC 7PnlUffqQGGZArRwyUZYkN8I5tz05KXFrLxn0PxerNMoVrZUOoxrOHx8aIK7LKPA pxndVDMMLrJ0F0ifFhCLF7olLlCuY6dt/Ru4PaSgI25bCRfWT2Sqjw1Sfya00k6H j623e64GBPxuQi9BLRI2mqtyiTJThq8moQKzHa47SbOFq0p+Av2gO6X5t9DaWbcy r7sJbaAobJ5PmgI4EtEOOnww8BDB2YgHwKqVdcSDd34zqFMtk0KT779M089WEOER khtixD03/dFquCZGBAkH =x9B8 -END PGP SIGNATURE- ___ 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 Jan 3, 2013 12:13 PM, Richard Hipp drh d...@sqlite.org@d...@sqlite.org sqlite.org d...@sqlite.org wrote: On Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym alaricala...@snell-pym.org.uk @snell- ala...@snell-pym.org.ukpym.org.uk ala...@snell-pym.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2012 09:33 AM, Nico Williams wrote: I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). That reminds me of a discussion I had with a dyed-in-the-wool git fan, of the make the history beautiful camp, who was a fan of making lots of tiny commits during development but then squashing them into a single neat patch to go onto the trunk. I was nervous about the history-loss this created, and one idea that I suggested as a compromise between our positions was a special kind of merge commit in the history that looked like a single commit containing the entire branch as a single patch in the UI, rather than like a merge of the topic branch containing the work. This would appear like rebasing the topic branch and squashing all the commits, but was actually just a merge in all respects other than how it looked in the timeline. Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. The changes might need to be logically broken up into several commits. So rather than squash everything into one commit the recipe might need to be more involved. For example, in developing the commits on that branch for some feature i might also have fixed bugs that need to be fixed separately upstream so that they can get cherry-picked onto branches for older release maintenance. Nico -- ___ 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.?
My understanding is that git rebase is used primarily to produce patches to be applied onto a particular tag or checkin of a destination repository, to give the same result as currently in the source repository, but without requiring the destination to do a git pull from the source repo, or to only pull a single prettified branch, rather than the history which made it happen. The source, however must have done a pull from the destination to get the start point of the patch. The essential feature is that the destination repo is somehow cleaner or of higher status or authority than the source repo. The source repo holds additional private content, perhaps including messy time-consuming development, and pulls at least certain content from the destination from time to time. When the source repo is finally ready to use, the messy development gets repackaged as a simple difference from the current state or some known recent state of the destination. I can't see what a rebase equivalent in fossil might do, which can't already be done using fossil diff (if you really want patches), or using private branches which get merged back into public ones from time to time, with only the public branches available to pull from. The fossil way of doing things (to my understanding) is to expose and preserve all history, while the whole idea of git rebase is to hide some of the history. If you really want rebase, you're probably looking in the wrong place, but I think you can already bend fossil to do it, without needing any changes to the tool itself. -- Christopher Vance ___ 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.?
[Sorry to break threading, but I unsubscribed, then saw this in the archives and re-subscribed just to answer, but I don't have the Message-ID.] On Sun, Dec 30, 2012, Joerg Sonnenberger wrote: 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. I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). Also, I'd like to be able to ask about previous rebasings of a given branch and be able to name them, something like branchname%N, where N is the Nth previous rebasing. This way I could checkout, diff, ... old versions of a branch. And then there'd be no need to create a copy of the victim branch prior to rebasing. This alternative to my first proposal strikes me as particularly useful. Thank you for mentioning it. Nico -- ___ 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 9:41 PM, Mike Meyer m...@mired.org wrote: 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. I unsubscribed. I resubscribed to answer Joerg's very useful comment, and to address your insinuation that I've been trolling: If I had written a ten-page post explaining in excruciating detail [...] 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. I was going to let you have the last word, and, indeed, I will since I will re-unsubscribe shortly. But I feel I must at least address this insinuation that I was trolling. I think any reasonable human being reviewing this thread will conclude that I've been sincere. I've explained in detail, and I've answered the questions that have been raised, such as here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10591.html and here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10593.html I think those two posts in particular are quite detailed and informative. Nor did I know that bringing up rebase would arouse fury. I knew it was controversial, but not that it was anathema, and I thought I could make an argument for a variant of rebase that should fit within the fossil philosophy (and I still think so; e pur si muove). Thus my wading in here could not be considered trolling. If I were to not give up I might be trolling, but trust me, I give up (unless we hear from the project's principals anything supportive, or if they ask questions that I should answer). Trust me, I feel awful about filling unknown subscribers inboxes with my responses on this thread, and the responses those have elicited. I have found your responses to me to be hostile, and downright silly. I've also briefly reviewed the rm/mv thread and I find similar silliness there by various members of the community. I am frustrated, and I acknowledge that I've am having trouble hiding my frustration. But I do think that you have shown an utter lack of hospitality and open-mindedness. This is why I will now abandon Fossil, even though there are many ways in which I think Fossil is superior to the competition -- your hostility turns me off. 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. These two posts: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10591.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10593.html answer your questions and explain in detail what I need to be able to do and why. Perhaps you missed them. You did respond once with this: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10602.html but you failed at reading comprehension, and by then I was ready to give up. But let me answer the one question you raise there: | I thought I did, but then you said rebase works on one branch. | | Except... | | So, if we have a branch called trunk with this history: | A---B---C---D | and a branch called new-feature with these commits | | Uh, that's *two* branches! What happened to rebase working on one branch? *git* rebase destructively affects ONE branch by making that one branch name point to a new line of commits that are not fast-forwards from the previous commit pointed to by that branch name. The rebase operation does additionally involve (read-only) an old base and new base commits. So, yes, rebase works on one branch. Rebase as a general
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On 31 December 2012 04:41, Mike Meyer m...@mired.org wrote: 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 a mass cherry-pick script, basically. You have an upstream trunk U and you branch B and in the simplest form rebase cherry-picks every single commint in B from the branching point to the tip one by one on top of U and marks the result as B. As has been pointed out this marking the result as B is the only destructive part which loses the original B and is unnecessary. Now the more involved version allows you to control how commits are picked. rebase presents you with a rebase recipe which shows the list of commits in B and all are marked with the default 'pick' which results with the above basic behaviour. You can edit the recipe to drop some commits, change the order in which they are picked, mark some for editing so rebase stops on them, mark some for squashing so rebase folds them into the previous commit. You can even select if the commit message of the squashed commit is appended or dropped but to edit the resulting message you have to run rebase again and mark for edit. Git add comes with a tool which allows you to pick only some files or some hunks from the checkout when creating a commit. It just shows the changed files and the hunks in the picked files one by one and asks you which to add. Sadly this tool is quite poorly integrated in git. When cherry-picking this cannot be used. To actually split a commit during rebase you have to mark the commit for editing, undo it, and then add parts of that commit as multiple commits possibly using the interactive add tool. When the commit adds files this is very error-prone. You can see that these tools are not available in fossil and with its web interface they could be presented in more friendly way than what the git commandline tools present. You can also see that while git has them they are not quite stellar. Thanks Michal ___ 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/31/12 11:17, Nico Williams wrote: [---] But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. -- Kind regards, Jan Danielsson ___ 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/31/2012 06:21 AM, Jan Danielsson wrote: On 12/31/12 11:17, Nico Williams wrote: [---] But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. I agree with Jan. I also think this thread and the mv/rm hostility suggest a change in tone for the mailing list which is more than a little embarrassing. I'm sorry you felt compelled to unsubscribe, Nico. ___ 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 Mon, Dec 31, 2012 at 12:01 PM, Steve Havelka yo...@q7.com wrote: On 12/31/2012 06:21 AM, Jan Danielsson wrote: On 12/31/12 11:17, Nico Williams wrote: [---] But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. I agree with Jan. I also think this thread and the mv/rm hostility suggest a change in tone for the mailing list which is more than a little embarrassing. I'm sorry you felt compelled to unsubscribe, Nico. I haven't yet re-unsubscribed. Joerg's note added hope that more participants might add something of value. And your and Jan's note provide much appreciated relief: I'm not alone in finding Mike's hostility needs calling out. Thanks! Nico -- ___ 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 too have been saddened by the two flame wars on this list lately. I have held onto the list because Fossil is super valuable to me and I want to stay in the loop. I can only hope that folks will learn to think before hitting reply in the new year... michael at barrow dot me +1.408.782.4249 -Original Message- From: Steve Havelka Sent: 12/31/2012 10:01 To: Fossil SCM user's discussion Subject: Re: [fossil-users] Fossil vs. Git/Mercurial/etc.? On 12/31/2012 06:21 AM, Jan Danielsson wrote: On 12/31/12 11:17, Nico Williams wrote: [---] But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. I agree with Jan. I also think this thread and the mv/rm hostility suggest a change in tone for the mailing list which is more than a little embarrassing. I'm sorry you felt compelled to unsubscribe, Nico. ___ 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 Dec 31, 2012, at 1:29 PM, Nico Williams n...@cryptonector.com wrote: I haven't yet re-unsubscribed. Joerg's note added hope Thank you for explaining rebase. It's not something I've ever needed to do, so I was skeptical of its value, and even more skeptical that it would ever be adopted by Fossil. While you have not converted me to an advocate, I've learned why you find it useful, and how it may be achieved without destroying history. I thank you for that, and for trying to be constructive and civil on this mailing list. e ___ 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/31/12 19:52, Doug Currie wrote: On Dec 31, 2012, at 1:29 PM, Nico Williams n...@cryptonector.com wrote: I haven't yet re-unsubscribed. Joerg's note added hope Thank you for explaining rebase. It's not something I've ever needed to do, so I was skeptical of its value, and even more skeptical that it would ever be adopted by Fossil. While you have not converted me to an advocate, I've learned why you find it useful, and how it may be achieved without destroying history. I thank you for that, and for trying to be constructive and civil on this mailing list. I wholeheartedly agree (with the entire paragraph). I have never used rebase, nor do I see any use for it in my daily work-flow. That being said, I've thought that about many things in the past until it was suddenly available to me. (And history is full of such examples for others as well. (3D acceleration? Linux users used to be quick to point out that only 1ame g4m3rz and n00bs need it [because it wasn't available on Linux]. Nowadays some Linux desktops even require 3D acceleration to run normally)). But more importantly, I don't see my current own personal lack of interest for rebase as a barrier to having the feature in fossil. As long as it doesn't break the DAG I'm fine (and Nico was clear about that being the intention). Things makes fossil more appealing and could help transition users to it from other systems is good in my book. Nico and Joerg have made it clear to me, as a rebase n00b, that there's a very fossil way to have rebase. And if I read Michal Suchanek correctly, we could even do it better than the arch-typical example of rebase (git). ..and I hope Nico's constructive and civil tone will be an inspiration to the community going forward. -- Kind regards, Jan Danielsson ___ 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 concur, the last month has seen a breakdown in the normally friendly exchanges. Might I suggest that we look on tomorrow as a new beginning - after all, we all survived the end of the Mayan calendar :-) This is open source software - so no one owes anyone any support. If you want changes then actions speak louder than words, contribute a patch - even if its not accepted it shows a level of commitment and understanding of the code base. If you can't write code, then for goodness sake don't approach those that can/do with anything that could be construed as an expectation of paid levels of support. For those that do write the code, not every new idea is bad. Building a community means taking the long view. Everyone, please remember; a piece of software is not the mother of your children, it doesn't need to be defended at all costs. richard. On Dec 31, 2012, at 10:34 AM, Michael L. Barrow mich...@barrow.me wrote: I too have been saddened by the two flame wars on this list lately. I have held onto the list because Fossil is super valuable to me and I want to stay in the loop. I can only hope that folks will learn to think before hitting reply in the new year... michael at barrow dot me +1.408.782.4249 ___ 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 Mon, Dec 31, 2012 at 8:21 AM, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 12/31/12 11:17, Nico Williams wrote: But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. At this point, I'd like to apologize the readers of the list, including Nico. My intent was not to be hostile or insulting. I was trying to get a description of the functionality he was looking for in terms of fossil's existing commands to be sure I correctly understood what he was suggesting. I got frustrated when he repeatedly ignored the question, and then outright refused to answer it, and clearly stepped over a line. Again, my apologies to all concerned. mike ___ 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.?
Thanks Mike, I appreciate this. BTW, I now have a pretty good idea of what fossil rebase would look like; the discussion was a success, largely thanks to Joerg's insight. I've also started looking at src/merge.c to have an idea of how to implement a version of fossil merge --cherrypick that doesn't commit the merged changes (this being necessary to implement the interactive rebase edit-a-commit option, as well as for squashing) -- this is the essential ingredient, after all, and it seems like all that has to happen is we need an option to not update any non-temp tables in merge_cmd(). I think that will be a trivial change, actually, as it'd be a small modification to the fossil merge --nochange logic. I'll stop here. In six months I may have time to actually implement, and in the meantime I'll sketch an implementation. Happy New Year! ___ 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, 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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams n...@cryptonector.com wrote: snip Actually I agree with most of Mike Meyer's reply, but I wanted to pick this paragraph apart: How many times have you submitted a patch to an upstream Well, phrasing it like that says that you are thinking git-style anyway. Let's assume a Fossil push with one commit nominated as this is my current contribution. and then been told to make a bunch of changes, That's only to be expected, so you create a new commit based on your previous nominated one, push it and tell them which is your new commit. re-organize your commits, I don't see why they (the centre) should do that. It's the result that matters, and if they want a pristine tree that includes only approved commits they can do that. (See below.) make specific changes to specific commits, Why, why, why? It's the result that matters, this is just rewriting _your_ history because they feel like it. and/or squash commits? Again, this is about them wanting a pristine tree. Their problem. Yeah, that's why rebase is good. Rebase is a lie! Rebase is a lie! Rebase is a lie! Now for the pristine tree thing. I don't agree with it but if that's what the project leads want, they can 1) not permit pushes or syncs, only pulls, and take only real patches, which they turn into commits themselves or 2) have two repositories, a working rep which everybody syncs with, and a clean one. Then have a command/script like accept commit-in-working-rep parent-in-clean-rep which creates a new child commit in the clean rep and does a pull back into the working rep, and which is simple in concept, though there will be issues about moves and deletes. Working this way also raises issues about what to do with wiki pages, tickets, and events. These approaches are not the outright lie that rebase tends to be, but merely the leads saying here is the history of the things we have approved. They are then depriving everyone of the history of blind alleys (which will therefore be followed again and again) and of the ideas whose time had not yet come (which will therefore have to be re-invented from scratch, or may even be forgotten altogether!). I think the correct way to deal with unwanted commits is to make proper use of branches, and perhaps to have a UI option which shows only things in a specified set of branches. Incidentally, there is nothing stopping you, as a remote, barely-trusted developer (which is what you are in that sort of scenario) from running the two-repository process yourself, so that you sync only from your clean repository. I also think that much of the mess in repositories that people seem to want to hide is the result of committing far too frequently, usually in the mistaken belief that their VCS is some sort of backup system. 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.?
(top post, due to the complexity of the previous post) I've found many git-fans that are completely ashamed of how they develop. And they would never make public how they commit things (how they use the VCS), so they don't accept other VCS that hasn't git rebasing capabilities. I can't tell what was first: the shame, shameful vcs usage, or the access to rebase feature. I dislike how git handles rebase, because by default it does not invite to rewriting commit logs. If you read git manuals, you are told that each commit (and its log) refers to a unique *file tree* (represented by the hash), and not to a *diff*. But then, they wrote 'rebase', which keeps the commit logs, but changes all the file trees they were meant for. Then you have commit logs that say I tested this, and this works. If you rebase that commit, that looses all that meaning. In fossil, a hash refers to a specific file tree, that never changes, and checkin comments refer to that hash. History rewriting also implies that what you could have in your brain memory on how you developed something could not match what you have left in the VCS - after mangling with rebase. I find this also another source of problems. Regards, Lluís. On Sat, Dec 29, 2012 at 02:53:23PM +, Eric wrote: On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams n...@cryptonector.com wrote: snip Actually I agree with most of Mike Meyer's reply, but I wanted to pick this paragraph apart: How many times have you submitted a patch to an upstream Well, phrasing it like that says that you are thinking git-style anyway. Let's assume a Fossil push with one commit nominated as this is my current contribution. and then been told to make a bunch of changes, That's only to be expected, so you create a new commit based on your previous nominated one, push it and tell them which is your new commit. re-organize your commits, I don't see why they (the centre) should do that. It's the result that matters, and if they want a pristine tree that includes only approved commits they can do that. (See below.) make specific changes to specific commits, Why, why, why? It's the result that matters, this is just rewriting _your_ history because they feel like it. and/or squash commits? Again, this is about them wanting a pristine tree. Their problem. Yeah, that's why rebase is good. Rebase is a lie! Rebase is a lie! Rebase is a lie! Now for the pristine tree thing. I don't agree with it but if that's what the project leads want, they can 1) not permit pushes or syncs, only pulls, and take only real patches, which they turn into commits themselves or 2) have two repositories, a working rep which everybody syncs with, and a clean one. Then have a command/script like accept commit-in-working-rep parent-in-clean-rep which creates a new child commit in the clean rep and does a pull back into the working rep, and which is simple in concept, though there will be issues about moves and deletes. Working this way also raises issues about what to do with wiki pages, tickets, and events. These approaches are not the outright lie that rebase tends to be, but merely the leads saying here is the history of the things we have approved. They are then depriving everyone of the history of blind alleys (which will therefore be followed again and again) and of the ideas whose time had not yet come (which will therefore have to be re-invented from scratch, or may even be forgotten altogether!). I think the correct way to deal with unwanted commits is to make proper use of branches, and perhaps to have a UI option which shows only things in a specified set of branches. Incidentally, there is nothing stopping you, as a remote, barely-trusted developer (which is what you are in that sort of scenario) from running the two-repository process yourself, so that you sync only from your clean repository. I also think that much of the mess in repositories that people seem to want to hide is the result of committing far too frequently, usually in the mistaken belief that their VCS is some sort of backup system. 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 ___ 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 Sat, 29 Dec 2012 16:20:32 +0100 Lluís Batlle i Rossell vi...@viric.name wrote: Top post due to... okay. The last three messages to this thread look somewhat alarming. In the first message of these, Mike Meyer, first ruled out the whole tool (Git) due to hating its optional feature and then proceeded with a fancastic technical argument against it: None. Zero. Nada. Never.. The second one, from Eric, contained the exclamation Rebase is a lie! repeated three times in a row. And now I'm reading about Git users ashamed for the histories they create. sarcasmYou guys do really sound as a religious sect./sarcasm Of course, this is a pro-Fossil list, but I fail to understand why such bashing of a rival DVCS and preaching are really required: those who might be converted are unlikely to read this list anyway (they're supposedly busy reading Pro Git now), and those who are reading this list admittedly prefer dry technical arguments. Actually, I intended to write a calm and purely technical response to Mike's message pointing out the ideas Git devs had while implementing rebasing (I failed to see in this thread any notice of using rebasing to help future bisecting, for instance), but the next two messages urged me to write this rather off-topic semi-rant. TL;DR I would really like to have such discussions be more technical and less zealous, if possible, please. (top post, due to the complexity of the previous post) [...] ___ 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 Sat, Dec 29, 2012 at 07:55:28PM +0400, Konstantin Khomoutov wrote: On Sat, 29 Dec 2012 16:20:32 +0100 Lluís Batlle i Rossell vi...@viric.name wrote: sarcasmYou guys do really sound as a religious sect./sarcasm :) well, I think that everyone expects different jobs to be done by a VCS. As for me, I like it to keep history as it happened. Then, fine if it has methods to reorganize the data in there, but without loosing the original history. Some people see the VCS as a tree where they organize the past development in the way they prefer, not necessarily linked to history. Actually, I intended to write a calm and purely technical response to Mike's message pointing out the ideas Git devs had while implementing rebasing (I failed to see in this thread any notice of using rebasing to help future bisecting, for instance), but the next two messages urged me to write this rather off-topic semi-rant. Git people that rewrite history (using rebase), will tell that they reorganize the commits so they become more logical. Git does not have a way of doing that without loosing the history of how all happened. Of course, git can be used without rebasing. I just haven't met anyone (even me, who contributes using git in different projects) who doesn't use rebase. And I use it, because the rest of the team don't want the git graphs crippled with _unnecessary_ merges. TL;DR Well, there you go. For some people, writing is easier than reading. ;) I would really like to have such discussions be more technical and less zealous, if possible, please. Well, I think all this ends up being a matter of taste. Everyone shows their views. It's like choosing an OS... Some people chose GNU/Linux, despite all the effort that it requires, because they prefer dealing with fdisk, filesystems, kernel updates, package managers, ... than to have the problems of Microsoft Windows (OS corruption, silent updates, hidden coed, dll hell, crashes, viruses, etc.). But some people prefer the problems of Windows. It's a matter of choosing the problems that annoy you less. :) And as I mentioned, some people see advantages in having those 'remote' trees locally, and there are situations where they can be convenient. But for most of the development I do in a VCS, that's far too heavy. Regards, Lluís. ___ 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 Sat, Dec 29, 2012 at 9:55 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: In the first message of these, Mike Meyer, first ruled out the whole tool (Git) due to hating its optional feature If you're going quote someone out of context, at least get their reasons right. You called rebase a killer feature of git. Ok, you like it. I consider rebase a serious misfeature, as it reflects an underlying philosophy for the tool that I flat disagree with. As far as I can tell, rebase is *not* optional. At least, it's enabled in my install of git, and I've never run into a way to disable it (or, for that matter, a git tutorial that didn't gush about how cool and wonderful the rebase command was). This should be compared to mercurial, where rebase is available - but in an extension that's turned off by default. *That's* an optional feature. You may enjoy trying to force your philosophy onto a tool that was designed with a completely different philosophy in mind, but I've got better things to do. There are DSCMs designed with a philosophy that I agree with. I'll use those, and not annoy the git folks by trying to get them to remove history-altering commands. and then proceeded with a fancastic technical argument against it: None. Zero. Nada. Never.. That wasn't a technical argument, that was an answer to a question you asked. Ok, maybe your question was rhetorical because you assumed everyone would have the same answer you do, but my answer is still None. I have never been asked to edit commits on a submitted patch. In any way. I don't think I've ever worked on a project were asking someone to edit commits would be considered acceptable behavior. You totally ignored my question to you, which asked for more details about your proposal. While rebase pretty much isn't going to happen (as I explained, it's contrary to the philosophy of fossil), you suggested a feature that sounded like it wouldn't clash with that philosophy. However, your description was rather vague. If you can get off your high horse long enough to describe what you'd like done in terms of commits and how they show up on the new branch, as opposed to rebase, it might get some consideration. But please don't continue wasting everyone's time by just complaining that people disagree with you. ___ 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 Sat, Dec 29, 2012 at 8:20 AM, Lluís Batlle i Rossell vi...@viric.namewrote: (top post, due to the complexity of the previous post) I've found many git-fans that are completely ashamed of how they develop. And they would never make public how they commit things (how they use the VCS), so they don't accept other VCS that hasn't git rebasing capabilities. I can't tell what was first: the shame, shameful vcs usage, or the access to rebase feature. I'm one of those losers who uses fossil as a sort of backup work area sync tool in addition to a pure SCM. Now I don't personally feel the label loser applies to me but I'm using it here because repeatedly now on this list, intentional or accidentally, folks are using words that leave the impression that people who use fossil this way are, well, losers. Judging others in this way is not constructive IHMO. Perhaps instead try to understand why people are compelled to do this wrong behavior and perhaps enhance the tool(s) to make it unnecessary. Rebase exists because it meets a real need. The question is, can that need be met in a more elegant way with fossil? I work on several projects that are spread out over different machines and are not always accessible to me from all locations where I work. I often (yes, often) have work in progress that is far from polished yet if I don't check it in I have no easy way to continue working later from a different location. The pragmatic solution for me is to check in the current state of the code regardless of whether it is polished or not. I even (horrors) occasionally check in stuff that won't compile. I could use private branches to keep this clean but that adds another thing to remember and manage to my already overfilled plate and I've found it very easy to accidentally lose work with private branches. What I would like is a way to mark branches as hidden. A hidden branch does not show up on the timeline. In the UI there would be a show hidden branches button but by default they would not show. I could do my messy work on a branch that I will later hide and when happy with the result merge to a branch that I would keep visible. This keeps history intact but makes a nice uncluttered clean view available that captures only the important aspects of development and hides the noise. Just my $0.02. Cheers and seasons greetings to all fossilers :) I dislike how git handles rebase, because by default it does not invite to rewriting commit logs. If you read git manuals, you are told that each commit (and its log) refers to a unique *file tree* (represented by the hash), and not to a *diff*. But then, they wrote 'rebase', which keeps the commit logs, but changes all the file trees they were meant for. Then you have commit logs that say I tested this, and this works. If you rebase that commit, that looses all that meaning. In fossil, a hash refers to a specific file tree, that never changes, and checkin comments refer to that hash. History rewriting also implies that what you could have in your brain memory on how you developed something could not match what you have left in the VCS - after mangling with rebase. I find this also another source of problems. Regards, Lluís. On Sat, Dec 29, 2012 at 02:53:23PM +, Eric wrote: On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams n...@cryptonector.com wrote: snip Actually I agree with most of Mike Meyer's reply, but I wanted to pick this paragraph apart: How many times have you submitted a patch to an upstream Well, phrasing it like that says that you are thinking git-style anyway. Let's assume a Fossil push with one commit nominated as this is my current contribution. and then been told to make a bunch of changes, That's only to be expected, so you create a new commit based on your previous nominated one, push it and tell them which is your new commit. re-organize your commits, I don't see why they (the centre) should do that. It's the result that matters, and if they want a pristine tree that includes only approved commits they can do that. (See below.) make specific changes to specific commits, Why, why, why? It's the result that matters, this is just rewriting _your_ history because they feel like it. and/or squash commits? Again, this is about them wanting a pristine tree. Their problem. Yeah, that's why rebase is good. Rebase is a lie! Rebase is a lie! Rebase is a lie! Now for the pristine tree thing. I don't agree with it but if that's what the project leads want, they can 1) not permit pushes or syncs, only pulls, and take only real patches, which they turn into commits themselves or 2) have two repositories, a working rep which everybody syncs with, and a clean one. Then have a command/script like accept commit-in-working-rep parent-in-clean-rep which creates a new child commit in the clean rep and
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Sat, 29 Dec 2012 10:24:05 -0600 Mike Meyer m...@mired.org wrote: In the first message of these, Mike Meyer, first ruled out the whole tool (Git) due to hating its optional feature If you're going quote someone out of context, at least get their reasons right. You called rebase a killer feature of git. No, that wasn't me. Ok, you like it. I consider rebase a serious misfeature, as it reflects an underlying philosophy for the tool that I flat disagree with. As far as I can tell, rebase is *not* optional. At least, it's enabled in my install of git, and I've never run into a way to disable it (or, for that matter, a git tutorial that didn't gush about how cool and wonderful the rebase command was). This should be compared to mercurial, where rebase is available - but in an extension that's turned off by default. *That's* an optional feature. No, an optional feature is the one you are not forced to use. I have a bunch of Git users in the company I work at who never touched `git rebase` though they supposedly read about it. They just don't need this feature and so they don't use it. If you call rebasing a non-optional feature, go ahead and claim all users of Git must commit to Subversion because Git includes the `git svn` tool and must send patches by e-mail as it also has `git format-patch`. If Git had rebasing instead of merging, you could make your point, but with the current state of affairs you can't. You may enjoy trying to force your philosophy onto a tool Not me, again. [...] But please don't continue wasting everyone's time by just complaining that people disagree with you. I suggest you to calm down. I see my plead to not being zealous was in vain, so just please calm down at least. ___ 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 Sat, Dec 29, 2012 at 10:51 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: I suggest you to calm down. I see my plead to not being zealous was in vain, so just please calm down at least. I am calm. Yes, I'm a little bit bothered about being insulted in various ways, but I'm trying to return the discussion to the technical merits of a proposal by getting a more detailed proposal from the OP. If you can't contribute to that technical discussion, please don't contribute to the discussion. mike ___ 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 Sat, Dec 29, 2012 at 8:53 AM, Eric e...@deptj.eu wrote: On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams n...@cryptonector.com wrote: snip Actually I agree with most of Mike Meyer's reply, but I wanted to pick this paragraph apart: How many times have you submitted a patch to an upstream Well, phrasing it like that says that you are thinking git-style anyway. Let's assume a Fossil push with one commit nominated as this is my current contribution. and then been told to make a bunch of changes, That's only to be expected, so you create a new commit based on your previous nominated one, push it and tell them which is your new commit. re-organize your commits, I don't see why they (the centre) should do that. It's the result that matters, and if they want a pristine tree that includes only approved commits they can do that. (See below.) It matters a great deal. Let's say you submit a patch for the main branch and the maintainers of an older release branch want to pull your patch in for a micro release of that older release. If your patches are broken up into suitable pieces then the maintainers might pull some of your commits (e.g., bug fixes) but not others (e.g., riskier ones, features). But if your commits were badly organized then the maintainers will have to copy/paste or apply chunks of patches -- very manual, risky processes. To me what you say indicates that you have very little experience with *large* projects. I've worked on quite a few large projects. I'd drop names, but to what end. The key is this *happens*. A lot. And it's not just because the VCS supports rebase: I've had to do rebasing with VCSes that don't have explicit support for it, because if that's what the upstream wants, then that's what the upstream gets (or nothing at all, but what if your job -that you're paid for- is to contribute to that upstream?). make specific changes to specific commits, Why, why, why? It's the result that matters, this is just rewriting _your_ history because they feel like it. Because that history is of a PRIVATE branch. PRIVATE. And the way I do it (go look at my github repos) is that I rebase brand new *copies* of the branch in question, so I never actually rewrite any history. (I thought I'd explained this. Hadn't I?) and/or squash commits? Again, this is about them wanting a pristine tree. Their problem. Or my problem: I want my fixes in. Or maybe I get paid to contribute to them. Nico -- ___ 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 Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell vi...@viric.name wrote: (top post, due to the complexity of the previous post) I've found many git-fans that are completely ashamed of how they develop. And they would never make public how they commit things (how they use the VCS), so they don't accept other VCS that hasn't git rebasing capabilities. If yoiu manage a *large* project, something on the order of OS/Net (the core of Solaris), say, then you need a clean tree for various reasons: - so maintenance of older releases is easier The maintainers of older releases can pull and merge specific fixes for specific bugs from the next-release branch. Without clean trees this is a disaster: you've lost organization of history, thus finding specific fixes -complete sets of commits for them- is often then as hard as just re-doing the work of fixing the bug in the first place. - to make it easier for *other* developers to find what happened later, when you're no longer around to ask questions of, or when you've forgotten the details. - to make it easier for reviewers to understand just what the heck your patches are about (this one fixes this one bug, that one adds this minor feature, ...) And so on. Really. Large projects need order, they need process. They need clean trees in official repos. Project repos? Let them have whatever ugly, dirty history. Official repos? No way. Without a way to clean history prior to pushing to / pulling into official repos a VCS is just hard to use effectively. That's my last word on this for a while. Take. Or leave it. Nico -- ___ 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 Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote: On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell vi...@viric.name wrote: (top post, due to the complexity of the previous post) I've found many git-fans that are completely ashamed of how they develop. And they would never make public how they commit things (how they use the VCS), so they don't accept other VCS that hasn't git rebasing capabilities. And so on. Really. Large projects need order, they need process. They need clean trees in official repos. Without a way to clean history prior to pushing to / pulling into official repos a VCS is just hard to use effectively. I'm not against that; I understand that teams of projects want to organize what their VCS history looks like. What I meant is that (by now) git has only one way of providing such clean trees: destroying the history. So, for that win (clean the trees at will), there is a forced work pattern: lose the history. For me the advantadges are less than the disadvantages. I think both can be achieved, in a VCS. For what I understand, Monotone has quite nice solutions to that. One thing is clean *visualisation* (or easy access, whatever), the other is modifying the raw historical data at the back. Git offers tools to manipulate the historical data, in order to achieve some visualisation. Regards, Lluís. ___ 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: tl;dr: we agree that public history should not get rewritten. You missed the point of when, where, and why I need rebase. Which is why I asked for clarification about that point. See below. On Fri, Dec 28, 2012 at 11:08 PM, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: Rebase is one of teh killer features of git. It certainly kills any interest I have in using git on a regular basis. Why? You don't have to use it if you don't want to. Because it indicates that the designers of git and I have a fundamental disagreement about what a SCM is for. This means it's very likely that using git is going to be one pita after another (which in fact it turns out to be). It all depends on the upstream though, doesn't it. I've worked with projects where the upstream want commits split because arguably a given commit does two things instead of one (e.g., fix a bug and a buglet). It doesn't all depend on the upstream. Part of it depends on you. You always have the option of saying No when someone makes such a request. You missed the point. The only thing that should ever get rebased is private branches (i.e., that no one should ever pull from). Once something's in an official repo it should never get rebased. You missed the point. Nothing should *ever* be rebased. It's a rewrite of history, which is a fundamentally bad thing. While a SCM should make generating patch files easy, it shouldn't require rewrites of history to do so. That's exactly what rebasing is. Here's the difference between git and fossil then: git has a nice tool for interactive rebasing (several, really, if you count git add -p as a tool for rebasing because it is so useful when splitting commits); fossil doesn't have that. Can I rebase with fossil? Yes, definitely. I just have to manually pick commits to merge, manually build the command lines, manually track the state of a complex rebase (this is the hardest part). And sure, I could script it, but the beauty of the git rebase -i interface should be built-in. This doesn't provide an answer to my question at all. A feature request can't simply be I need other-scm's foo command. Especially when said command is one that is philosophically unsuited to fossil. For instance, I'd love to have hg's rollback command, but I'd never suggest it with those words. Instead, I described what it did, and suggested a command syntax, and possibilities for some problematic cases. I already got that you have a need for rebase that you think is compatible with fossil. You've provided a use case, and I agree that fossil could handle that reasonably. But you haven't actually proposed a new command for fossil, other than rebase, which has already been rejected multiple times. Do you want a more controlled merge for this? I know I'd like a more controlled merge; compared to perforce's 3-step merge, everything else feels like throwing code at the wall and hoping the right bits stick. But maybe you want a less-controlled merge. I can't tell from the descriptions you've given. -- 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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote: And so on. Really. Large projects need order, they need process. They need clean trees in official repos. Without a way to clean history prior to pushing to / pulling into official repos a VCS is just hard to use effectively. I'm not against that; I understand that teams of projects want to organize what their VCS history looks like. What I meant is that (by now) git has only one way of providing such clean trees: destroying the history. That's a strawman. I very specifically suggested that a fossil rebase operation should *always* copy the branch being rebased and then rebase that copy. Now what on Earth could possibly be objectionable about that? Nico -- ___ 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 Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer m...@mired.org wrote: You missed the point. Nothing should *ever* be rebased. It's a rewrite of history, which is a fundamentally bad thing. While a SCM should make generating patch files easy, it shouldn't require rewrites of history to do so. You missed my proposal that a fossil rebase operation always copy the branch being rebased and rebase that copy. It was in my very first post on this thread: | Fossil is designed to avoid destructive operations. Rebasing is a | destructive operation. A compromise would be to allow rebasing but | into a new branch, leaving the original alone -- this is how I do | rebases in git anyways. [...] I have to wonder how so many people missed it. My guess: those who missed it really can't get past the idea that git's rebase is destructive, therefore nothing even remotely like it can be considered, even if it explicitly prevents destruction. But that's not much of an excuse: that was a total of three short paragraphs you could have read before launching into a massive sub-thread. Perhaps we need a word for non-destructive (copying) rebase that -being a different word- fails to arouse such [misplaced] ire. Nico -- ___ 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 Sat, Dec 29, 2012 at 05:37:35PM -0600, Nico Williams wrote: On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote: And so on. Really. Large projects need order, they need process. They need clean trees in official repos. Without a way to clean history prior to pushing to / pulling into official repos a VCS is just hard to use effectively. I'm not against that; I understand that teams of projects want to organize what their VCS history looks like. What I meant is that (by now) git has only one way of providing such clean trees: destroying the history. That's a strawman. I very specifically suggested that a fossil rebase operation should *always* copy the branch being rebased and then rebase that copy. Now what on Earth could possibly be objectionable about that? Ah sorry, I was only talking about my objections against git rebase. I don't know the best way to implement a feature that allows creating 'new history' at will (not destroying the old). All I can imagine sounds like a lot of work. :) Regards, Lluís. ___ 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 Sat, Dec 29, 2012 at 5:47 PM, Lluís Batlle i Rossell vi...@viric.name wrote: Ah sorry, I was only talking about my objections against git rebase. I don't know the best way to implement a feature that allows creating 'new history' at will (not destroying the old). All I can imagine sounds like a lot of work. :) The basic machinery (cherry-pick) is there. The main piece is the interactive rebase, which is really popping the user into $EDITOR to select the order of various operations, and which those are. So there's a) code to select commits, code to format that into a file the user will edit, spawn $EDITOR, then parse the result, then execute it. The execution part requires keeping state and is a bit tricky. The hardest part, I think would be anything like git add -p. ___ 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: On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer m...@mired.org wrote: You missed the point. Nothing should *ever* be rebased. It's a rewrite of history, which is a fundamentally bad thing. While a SCM should make generating patch files easy, it shouldn't require rewrites of history to do so. You missed my proposal that a fossil rebase operation always copy the branch being rebased and rebase that copy. It was in my very first post on this thread: I didn't miss it. I asked for clarification, for two reasons: 1) Rebase involves two branches, both of which get changed. Your proposal only mentions one. Given that I'm not all that familiar with rebase, I have *no* idea what this means in terms of additions to the history tree. 2) Your use case (generating patches to make upstream happy) isn't one I've ever experienced, but it doesn't sound like it needs to change the tree at all. So, for the third time, can you describe your proposed new feature *without* saying the words git or rebase. -- 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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
I'm pretty sure that rebase or its equivalents will never be a part of Fossil. Given that there are tools out there (like Git) that feature this functionality that some (and I stress it's only *some*) users want, perhaps this following question is to practical but … why not use Git, the tool that has the feature you want? This arguing over whether rebase is good or bad and whether you're a good or bad person for wanting it is futile. I'm pretty damned sure that it's not going to ever be added (given Richard Hipp's philosophical stance on rewriting repository history). TL;DR version: stop whining and use Git if you want Git. On 30 December 2012 12:29, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer m...@mired.org wrote: You missed the point. Nothing should *ever* be rebased. It's a rewrite of history, which is a fundamentally bad thing. While a SCM should make generating patch files easy, it shouldn't require rewrites of history to do so. You missed my proposal that a fossil rebase operation always copy the branch being rebased and rebase that copy. It was in my very first post on this thread: I didn't miss it. I asked for clarification, for two reasons: 1) Rebase involves two branches, both of which get changed. Your proposal only mentions one. Given that I'm not all that familiar with rebase, I have *no* idea what this means in terms of additions to the history tree. 2) Your use case (generating patches to make upstream happy) isn't one I've ever experienced, but it doesn't sound like it needs to change the tree at all. So, for the third time, can you describe your proposed new feature *without* saying the words git or rebase. -- 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 -- 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 Sat, Dec 29, 2012 at 10:29 PM, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: You missed my proposal that a fossil rebase operation always copy the branch being rebased and rebase that copy. It was in my very first post on this thread: I didn't miss it. I asked for clarification, for two reasons: 1) Rebase involves two branches, both of which get changed. Your proposal only mentions one. Given that I'm not all that familiar with rebase, I have *no* idea what this means in terms of additions to the history tree. In git, the rebase command rebases only the current branch. There's one or two other things to specify: upstream and, optionally, newbase, but these two need not be branch names. What I'm proposing is that in fossil the rebase operation create a new branch named after the currently checked out branch (or named by the user) with the rebased contents, leaving the original alone. The new branch should get checked out too (for obvious reasons, as the process of rebasing needs interim points checked out, and anyways, the user is likely to want the new branch checked out. 2) Your use case (generating patches to make upstream happy) isn't one I've ever experienced, but it doesn't sound like it needs to change the tree at all. It produces a different set of commits to be sent upstream than I had before the rebase -- that's a change to the tree, though, really, it's a new branch. In git the branch name is then changed to point to the new line of commits, and this change is what we all consider destructive. That you've not experienced this says nothing about the reality of it. For me the lack of rebase in any VCS is near fatal -- it's generally possible to obtain the same effect, even with fossil, but at the cost of much manual labor or much labor spent automating rebase tasks (never as well as git rebase does it anyways). So, for the third time, can you describe your proposed new feature *without* saying the words git or rebase. No: it's too much work, and many people understand git rebase, and it has documentation I can refer to. I don't want to copy that documentation nor find a way of expressing the same concepts differently -- that would be a waste of my time and would confuse all those users who know what git rebase is. I'd much rather instead offer a description as incremental change to git rebase. Given these command-line synopses from the git-rebase manpage: git rebase [-i | --interactive] [options] [--onto newbase] upstream [branch] git rebase [-i | --interactive] [options] --onto newbase --root [branch] my proposal is for: fossil rebase [-i | --interactive] [options] [--new newbranch] [--onto newbase] upstream [branch] fossil rebase [-i | --interactive] [options] [--new newbranch] --onto newbase --root [branch] if newbranch is not given then newbranch would be derived from the selected branch (or current) by adding a suffix -1 or by incrementing the number if branch ends in -number. Nico -- ___ 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 Sat, Dec 29, 2012 at 10:49 PM, Michael Richter ttmrich...@gmail.com wrote: I'm pretty sure that rebase or its equivalents will never be a part of Fossil. Given that there are tools out there (like Git) that feature this functionality that some (and I stress it's only some) users want, perhaps this following question is to practical but … why not use Git, the tool that has the feature you want? This arguing over whether rebase is good or bad and whether you're a good or bad person for wanting it is futile. I'm pretty damned sure that it's not going to ever be added (given Richard Hipp's philosophical stance on rewriting repository history). What is it about rebase that causes so many to miss the idea of a rebase that is NOT destructive because it creates a new branch instead of doing a destructive change to an existing branch? I shall wait for D. Richard Hipp's word as to any kind of rebase never making it into Fossil. TL;DR version: stop whining and use Git if you want Git. You fail reading comprehension. I do use git, nearly exclusively. And I use rebase. And I use it in a way that is non-destructive (because I always rebase fresh branches that are copies of the ones I want to rebase). I happen to think that Fossil has a superior architecture and design. I'd like to use Fossil, but I can't, and I've explained why. I've also explained why I'm unlikely to be the only user who needs this one feature. Nico -- ___ 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: What I'm proposing is that in fossil the rebase operation create a new branch named after the currently checked out branch (or named by the So, for the third time, can you describe your proposed new feature *without* saying the words git or rebase. No: it's too much work, and many people understand git rebase, and -1. -- 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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On 30 December 2012 12:56, Nico Williams n...@cryptonector.com wrote: What is it about rebase that causes so many to miss the idea of a rebase that is NOT destructive because it creates a new branch instead of doing a destructive change to an existing branch? I don't know. You won't explain it. It's too much work, remember? I shall wait for D. Richard Hipp's word as to any kind of rebase never making it into Fossil. http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01792.html That alone would be a pretty strong indicator given the context of the thread it's in. Too, the fact that *two years after* the first round of requests for rebase there is still no rebase functionality and this conversation is coming up *yet again* is another pretty strong indicator. TL;DR version: stop whining and use Git if you want Git. You fail reading comprehension. No, you just don't like my interpretation. I do use git, nearly exclusively. And I use rebase. And I use it in a way that is non-destructive (because I always rebase fresh branches that are copies of the ones I want to rebase). Good. So you're happy with Git. Keep using Git. You like its features and you don't like the fact Fossil doesn't have these features (and that it likely never will). There's no reason to make every DSCM turn into a Git clone. (Indeed there's every reason *not* to have a myriad of Git clones out and about!) I happen to think that Fossil has a superior architecture and design. Except part of its design is *no rewriting of history*. Hence, no rebase in the Git sense. I'd like to use Fossil, but I can't, and I've explained why. So use Git. Nobody here is calling you a bad person because you're using Git. Nobody here is holding a gun to your head forcing you to use not-Git. I've also explained why I'm unlikely to be the only user who needs this one feature. This is the C++ approach to things: add every conceivable feature because someone, somewhere might want to use it. The result is a language that should be an embarrassment with so much of a learning curve^H^H^H^H^H*cliff*that very few people (if any) could really be called expert users. (The funniest part was that the standards committee decided to address this specific problem by *adding even more features*.) There's use cases for every bizarre feature in every bizarre SCM (distributed or otherwise) out there. Let's not turn Fossil into the C++ of DSCMs, shall we? If you *really, positively, absolutely* must have rebase, Git is that-a-way. Insisting that Fossil should turn into Git is not a viable argument. -- 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 30 December 2012 13:02, Nico Williams n...@cryptonector.com wrote: On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer m...@mired.org wrote: So, for the third time, can you describe your proposed new feature *without* saying the words git or rebase. No: it's too much work, and many people understand git rebase, and -1. So is that a -1 to the attitude, the proposal, or both? I can't tell. If the attitude, can you explain why you would want an explanation of rebase in words other than those that have already been used (probably by so many)? What's the problem with making reference to git? Is git anathema? Is this NIH syndrome? I can't speak for Mike Meyer, but I'd -1 that attitude because you're basically saying, stripping away the pretty posturing, I WANT THIS NEW FEATURE AND I WON'T EXPLAIN IT TO YOU BECAUSE THAT'S TOO MUCH WORK FOR ME INSTEAD I WANT YOU TO DO THE WORK FOR ME! If you can't (or, rather, won't!) explain Git's rebase command to people who *very obviously are not using Git* and who are equally obviously *not interested in learning or using Git*, then your attitude does, in fact, reek. You want the feature. We don't. It's kind of up to *you* to explain to *us * (in *our* terms!) why it's important and how it doesn't undermine the very point of Fossil's design. -- 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.?
Michael Richter decía, en el mensaje Re: [fossil-users] Fossil vs. Git/Mercurial/etc.? del Domingo, 30 de Diciembre de 2012 02:11:46: There's use cases for every bizarre feature in every bizarre SCM (distributed or otherwise) out there. Let's not turn Fossil into the C++ of DSCMs, shall we? If you *really, positively, /absolutely/* must have rebase, Git is that-a-way. Insisting that Fossil should turn into Git is not a viable argument. *standing ovation* -- o-= Marcelo =-o ___ 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 Sat, Dec 29, 2012 at 11:11 PM, Michael Richter ttmrich...@gmail.com wrote: On 30 December 2012 12:56, Nico Williams n...@cryptonector.com wrote: What is it about rebase that causes so many to miss the idea of a rebase that is NOT destructive because it creates a new branch instead of doing a destructive change to an existing branch? I don't know. You won't explain it. It's too much work, remember? You had left me under the impression that you knew what git rebase is. Fair enough, here we go: A rebase operation takes a branch (typically the current one) and two commits (oldbase and newbase) in the repository and then a) computes the set of commits that are in the branch since oldbase then b) creates a new line of commits that consists of newbase plus the commit set computed in (a), each commit in that set applied as a delta onto newbase, merging as needed. So, if we have a branch called trunk with this history: A---B---C---D and a branch called new-feature with these commits A---B---C---a---b---c where commits a, b, and c are in the new-feature branch but not in trunk, and clearly we're missing commit D from trunk in new-feature, we want to end up with: A---B---C---D---a'---b'---c' Where a', b', and c' are each based on commits a, b, and c, but merged onto D. In *git* this is a destructive operation because the new-feature branch's HEAD is made to be c', which is not a linear history from c. But if the rebase operation creates a new branch whose HEAD points to c' then there's nothing destructive. Other things that can be redone in a rebase would include: A---B---C---D---a'---c'---b' (re-order commits, not merely change the base of commit a) A---B---C---D---a'---c' (drop a commit, not merely change the base of a) A---B---C---D---abc' (merge all three of a, b, and c, into abc') A---B---C---D---ac'---b' (re-order and merge some) A---B---C---D---a1'---a2'---b'---c' (split a and rebase) A---B---C---abc' (no rebase, just merge the top three commits) These are things that upstream maintainers of large projects quite often insist upon. Nico -- ___ 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 30 December 2012 13:23, Nico Williams n...@cryptonector.com wrote: A rebase operation takes a branch (typically the current one) and two commits (oldbase and newbase) in the repository and then a) computes the set of commits that are in the branch since oldbase then b) creates a new line of commits that consists of newbase plus the commit set computed in (a), each commit in that set applied as a delta onto newbase, merging as needed. And why would I want to do this? Explain as you would to, say, a small child. So, if we have a branch called trunk with this history: A---B---C---D and a branch called new-feature with these commits A---B---C---a---b---c where commits a, b, and c are in the new-feature branch but not in trunk, and clearly we're missing commit D from trunk in new-feature, we want to end up with: A---B---C---D---a'---b'---c' Where a', b', and c' are each based on commits a, b, and c, but merged onto D. Why not, for example, just merge c into D or vice versa? I really don't see what modifying history does here. Possibly because I lack the imagination to put any concrete examples into A, B, C, D, a, b, c, a', b', c' where this would be a desirable feature. Could you be more specific? A---B---C---D---a'---c'---b' (re-order commits, not merely change the base of commit a) Why? A---B---C---D---a'---c' (drop a commit, not merely change the base of a) Why? A---B---C---D---abc' (merge all three of a, b, and c, into abc') Why? A---B---C---D---ac'---b' (re-order and merge some) Why? A---B---C---D---a1'---a2'---b'---c' (split a and rebase) Why? A---B---C---abc' (no rebase, just merge the top three commits) Why? These are things that upstream maintainers of large projects quite often insist upon. And why do they do this? I kinda/sorta get the mechanism. I just don't see the motivation. (And upstream maintainers insist upon this is not motivation, it's just moving the question of motivation around.) -- 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 Sat, Dec 29, 2012 at 11:33 PM, Michael Richter ttmrich...@gmail.com wrote: On 30 December 2012 13:23, Nico Williams n...@cryptonector.com wrote: A rebase operation takes a branch (typically the current one) and two commits (oldbase and newbase) in the repository and then a) computes the set of commits that are in the branch since oldbase then b) creates a new line of commits that consists of newbase plus the commit set computed in (a), each commit in that set applied as a delta onto newbase, merging as needed. And why would I want to do this? Explain as you would to, say, a small child. Short version: because upstream tells you to. Longer version: first because upstream wants patches that apply cleanly, but if you don't have commit D in the new-feature branch and your commits a, b, and/or c require merging with D, then the upstream will tell you to update your patches (it's *your* job to do such merges), second because upstream may want you to re-organize your work (as I've explained before; no need to repeat). So, if we have a branch called trunk with this history: A---B---C---D and a branch called new-feature with these commits A---B---C---a---b---c where commits a, b, and c are in the new-feature branch but not in trunk, and clearly we're missing commit D from trunk in new-feature, we want to end up with: A---B---C---D---a'---b'---c' Where a', b', and c' are each based on commits a, b, and c, but merged onto D. Why not, for example, just merge c into D or vice versa? I really don't see what modifying history does here. Possibly because I lack the imagination to put any concrete examples into A, B, C, D, a, b, c, a', b', c' where this would be a desirable feature. Could you be more specific? Because D is already upstream, therefore to remove D from upstream would be a destructive operation. The goal is to produce new commits that apply cleanly to trunk upstream. Again, if I send a, b, and c upstream and D was missing in my branch then my commits may not apply cleanly. Even if they do the commit hashes will change as in the upstream the parent of a will be D, not C. A---B---C---D---a'---c'---b' (re-order commits, not merely change the base of commit a) Why? Because upstream may ask for it. For example, if I wrote a test first, committed it, then a bug fix -- my mistake, but I should have done it the other way around (though I might not have known the upstream maintainer's order preferences upfront). A---B---C---D---a'---c' (drop a commit, not merely change the base of a) Why? Because it turns out that commit b was lame. Or because upstream decided to reject commit b but commits a and c still stood on their own. A---B---C---D---abc' (merge all three of a, b, and c, into abc') Why? Because upstream thought these three belong as one. (E.g., b might fix a bug introduced by a, and c might fix a typo in b.) A---B---C---D---ac'---b' (re-order and merge some) Why? Commit c might fix a typo in commit a, while commit b might be unrelated. Squashing (git term) c into a then helps keep history clean upstream. Upstream likes clean history in official repos. A---B---C---D---a1'---a2'---b'---c' (split a and rebase) Why? Because commit a did two separable things and upstream wants them separated so that, for example, a1' can be pulled into an older release's bugfix branch without pulling in a2'. A---B---C---abc' (no rebase, just merge the top three commits) Why? Here I'm not contributing abc' just yet. I'm still working but I know upstream wants commits a, b, and c merged. Eventually I'll have to rebase onto D, but I want to do that later. These are things that upstream maintainers of large projects quite often insist upon. And why do they do this? I kinda/sorta get the mechanism. I just don't see the motivation. (And upstream maintainers insist upon this is not motivation, it's just moving the question of motivation around.) Because they want clean history. If commit b fixes a bug introduced by commit a then why should that bug -which had never been upstream to begin with- exist upstream in the middle of the history? Not only is there no reason to want that upstream, but having it upstream will only add to the burden of someone reviewing the history to understand it or specific changes in it. Nico -- ___ 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 30 December 2012 14:00, Nico Williams n...@cryptonector.com wrote: And why do they do this? I kinda/sorta get the mechanism. I just don't see the motivation. (And upstream maintainers insist upon this is not motivation, it's just moving the question of motivation around.) Because they want clean history. This is precisely why I maintain that you're not going to see a rebase in Fossil. Quoting from http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01792.html: *There are differing philosophies here. Some say it is important to present a clean, linear narrative of what took place - a narrative that is easy to follow and easy to understand. Others say that it is more important to present history as it actually occurred, in all its messy detail, not how you wish it had occurred. Git and Hg tend more toward the first view whereas Fossil leans toward the second.* That's the Voice of God for Fossil speaking there. What you want is exactly not what Fossil was built to provide. -- 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 Sun, Dec 30, 2012 at 12:09 AM, Michael Richter ttmrich...@gmail.com wrote: On 30 December 2012 14:00, Nico Williams n...@cryptonector.com wrote: Because they want clean history. This is precisely why I maintain that you're not going to see a rebase in Fossil. Quoting from http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01792.html: There are differing philosophies here. Some say it is important to present a clean, linear narrative of what took place - a narrative that is easy to follow and easy to understand. Others say that it is more important to present history as it actually occurred, in all its messy detail, not how you wish it had occurred. Git and Hg tend more toward the first view whereas Fossil leans toward the second. There's room for interpretation, and for persuasion. Clearly the history in an official repo must reflect what happened. But the history I choose to present in a contribution is entirely in my hands to decide how it looks (and the upstream may impose their own requirements). If it wasn't in the official repos, did it happen? Fossil didn't always have private branched. It does now. Isn't that a concession that sets precedent? At Sun, for example, we had official repos for products (gates), project repos aiming at eventual integration into product gates, and individual repos. Individuals pushed to either project gates or product gates, depending on what they were working on. Product gates were always archived and available, even for ancient releases of the products. Project gates were generally (but not always) archived and available. Individual repos were generally littered across the place, with no real way for one to find them without asking the developer working on them. History was cleaned prior to pushing to gates higher up the hierarchy, but past history in product gates was never rewritten. This worked spectacularly well. Who wants to see typos made and fixed before the commits landed on the product gates?? Answer: no one, because such things are useless and a burden. The room I see for interpretation and/or persuasion lies in that not all history is equally valuable. Nico -- ___ 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 12:19 AM, Nico Williams n...@cryptonector.com wrote: There's room for interpretation, and for persuasion. That's one of the things that happen when we build religions: heresy. Is this heresy? You can't say. Maybe not even D. Richard Hipp can say. Unless I'm willing to fork fossil and do it my way (I'm not) and if D. Richard Hipp declares this heresy, then it's all academic. I would recommend a less religious approach though. Our thinking on technical matters evolves. Mine does. I hope yours does too. This isn't *real* religion. There's no moral principles at stake. Society is not at risk, not from this argument anyways. ___ 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 30 December 2012 14:19, Nico Williams n...@cryptonector.com wrote: There are differing philosophies here. Some say it is important to present a clean, linear narrative of what took place - a narrative that is easy to follow and easy to understand. Others say that it is more important to present history as it actually occurred, in all its messy detail, not how you wish it had occurred. Git and Hg tend more toward the first view whereas Fossil leans toward the second. There's room for interpretation, and for persuasion. Not really, no. Any interpretation that says anything other than it is more important to present history as it actually occurred isn't interpretation, it's dissembling. Fossil didn't always have private branched. It does now. Isn't that a concession that sets precedent? I'd say the private branches pretty much eliminate your need for rebasing entirely given what you've described as rebasing. Make your mess in your private branches. Expose the pretty stuff in non-private branches. Problem solved. At Sun, for example, we had official repos for products (gates), project repos aiming at eventual integration into product gates, and individual repos. Individuals pushed to either project gates or product gates, depending on what they were working on. Product gates were always archived and available, even for ancient releases of the products. Project gates were generally (but not always) archived and available. Individual repos were generally littered across the place, with no real way for one to find them without asking the developer working on them. History was cleaned prior to pushing to gates higher up the hierarchy, but past history in product gates was never rewritten. This worked spectacularly well. Who wants to see typos made and fixed before the commits landed on the product gates?? Answer: no one, because such things are useless and a burden. So … have a public-facing clean repository and a private dirty repository with private branches? Again, I don't see what screwing with the DAG of the SCM buys you besides trouble. -- 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 Sun, Dec 30, 2012 at 12:40 AM, Michael Richter ttmrich...@gmail.com wrote: On 30 December 2012 14:19, Nico Williams n...@cryptonector.com wrote: There are differing philosophies here. Some say it is important to present a clean, linear narrative of what took place - a narrative that is easy to follow and easy to understand. Others say that it is more important to present history as it actually occurred, in all its messy detail, not how you wish it had occurred. Git and Hg tend more toward the first view whereas Fossil leans toward the second. There's room for interpretation, and for persuasion. Not really, no. Any interpretation that says anything other than it is more important to present history as it actually occurred isn't interpretation, it's dissembling. But you're coming around, check it: Fossil didn't always have private branched. It does now. Isn't that a concession that sets precedent? I'd say the private branches pretty much eliminate your need for rebasing entirely given what you've described as rebasing. Make your mess in your private branches. Expose the pretty stuff in non-private branches. Problem solved. Sure! You came around, see? Except that it's not easy to clean up history in private branches with fossil. You have to manually cherry-pick each commit from one branch onto another in the order that you want. Either splitting or merging commits (forget which) is harder still. git gives you a nice interface for doing this. At Sun, for example, we had official repos for products (gates), project repos aiming at eventual integration into product gates, and individual repos. Individuals pushed to either project gates or product gates, depending on what they were working on. Product gates were always archived and available, even for ancient releases of the products. Project gates were generally (but not always) archived and available. Individual repos were generally littered across the place, with no real way for one to find them without asking the developer working on them. History was cleaned prior to pushing to gates higher up the hierarchy, but past history in product gates was never rewritten. This worked spectacularly well. Who wants to see typos made and fixed before the commits landed on the product gates?? Answer: no one, because such things are useless and a burden. So … have a public-facing clean repository and a private dirty repository with private branches? Again, I don't see what screwing with the Exactly. Nothing awful about that, is there. DAG of the SCM buys you besides trouble. There... is no playing around with the DAG of the SCM. A rebase is just a new branch in this scheme. New branches are hardly playing around with the DAG of the SCM. This is true even in git -- the old commits in the repo don't change, they're not even deleted -- the only thing destructive git does in a rebase is change commit that a branch name points to. So if you want to go from A---B---C---a---b---c to A---B---C---D---ac'---b' you'll find that a, b, and c are still left behind. In fossil there'd be a new branch name to refer to the line of commits headed by b'. In git c is no unreachable, unless there was some other branch or tag referring to it, but c is still in the repo, and if there's no other way to reach it there's always the reflog. You seem to think that git rewrites history. It does not. The only destructive actions in git are: changing what a branch or tag point to, and pruning unreachable commits. And yes, rebasing private branches is easy, except it's a very manual task in fossil, so it's not easy. ___ 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: On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer m...@mired.org wrote: So, for the third time, can you describe your proposed new feature *without* saying the words git or rebase. No: it's too much work, and many people understand git rebase, and -1. So is that a -1 to the attitude, the proposal, or both? The proposal. It smells. Without a better description of the problem than I need rebase, its impossible to do the evalutation of alternative solutions that good engineering practices call for to decide if the smell is an indication of a real problem or not. Minimally, knowing how you solve this problem using existing fossil commands would help decide if to much work is a valid evaluation, a straw man, an overlooked fossil feature, or a need for a minor workflow tweak. But technical descriptions of why things like perforce's three-step merge or mercurial queues or any other alternatives mentioned here aren't acceptable are pretty much required. Given a proper problem description, I'd be glad to do that for the ones I'm familiar with. I'd also be happy if you want to provide those, but expect that it's also to much work. -- 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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Sun, 30 Dec 2012 14:40:27 +0800 Michael Richter ttmrich...@gmail.com wrote: I'd say the private branches pretty much eliminate your need for rebasing entirely given what you've described as rebasing. Make your mess in your private branches. Expose the pretty stuff in non-private branches. Private-branches are missing one, imho, important feature: ability to handle single branch. For now it's all or nothing which makes the above 'workaround' not so easy. Sincerely, Gour -- One is understood to be in full knowledge whose every endeavor is devoid of desire for sense gratification. He is said by sages to be a worker for whom the reactions of work have been burned up by the fire of perfect knowledge. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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 should also point out that in the Sun model once every one or two bi-weekly mini-releases of the product gates the project gates would have to catch up. Catching up in a way that leaves project commits ahead of the product gate is effectively rebasing, which breaks child gates, which is bad. So what we did is we... created new project branches that got rebased to the upstream and then the child (individual) repos did the moral equivalent of git rebase --onto onto the new project gate branches. Note that history did not get re-written in the project gates: new branches appeared with similar, but different, history to their predecessors, but all stuck around forever. ___ 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: On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter ttmrich...@gmail.com wrote: On 30 December 2012 12:56, Nico Williams n...@cryptonector.com wrote: What is it about rebase that causes so many to miss the idea of a rebase that is NOT destructive because it creates a new branch instead of doing a destructive change to an existing branch? I don't know. You won't explain it. It's too much work, remember? You had left me under the impression that you knew what git rebase is. Fair enough, here we go: I thought I did, but then you said rebase works on one branch. Except... So, if we have a branch called trunk with this history: A---B---C---D and a branch called new-feature with these commits Uh, that's *two* branches! What happened to rebase working on one branch? But the crux of the issue is right here: 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. -- 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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
Rebase is one of teh killer features of git; the other killer features of git are in Fossil already, but rebase is not. And fossil adds its own killer features: built-in web service, JSON RESTful API, wiki and tickets integrated (and versioned, natch). How many times have you submitted a patch to an upstream and then been told to make a bunch of changes, re-organize your commits, make specific changes to specific commits, and/or squash commits? Yeah, that's why rebase is good. Fossil is designed to avoid destructive operations. Rebasing is a destructive operation. A compromise would be to allow rebasing but into a new branch, leaving the original alone -- this is how I do rebases in git anyways. I would love to see rebasing along these lines in fossil. With rebase I could seriously consider leaving git behind, using a fossil-git gateway when contributing to upstreams that use git. Nico -- ___ 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: Rebase is one of teh killer features of git. It certainly kills any interest I have in using git on a regular basis. How many times have you submitted a patch to an upstream and then been told to make a bunch of changes, re-organize your commits, make specific changes to specific commits, and/or squash commits? Yeah, that's why rebase is good. None. Zero. Nada. Never. The thing is, I actually submit a *patch*, not a pull request or a commit history or anything that would invite such a request. That's also how I work merges between branches: the mrege is a single commit that incorportes all the changes from the other branch, or on rare occaisions a cherry-picked set of changes. The history is still there in the old branch if I want to review it, but the commit log for the trunk is nice and clean. That's one of the philosophical differences that determine which of the DSCMs you want to use. If the philosophy is that history is important, then you never rebase, and nobody would dream of asking you to make changes to your commits beyond making the comments more accurate. Rebase is not merely unnecessary, but anathema. If, on the other hand, the repository is considered to be part of the public face of the project like user docs or the web site, then editing it for readability and marketing purposes is SOP, and rebase is a critical tool. Fossil is designed to avoid destructive operations. Rebasing is a destructive operation. A compromise would be to allow rebasing but into a new branch, leaving the original alone -- this is how I do rebases in git anyways. I think you need to be mor explicit. Rebase is used for a number of different things, most in my (admittadly limited) experience with rebase it involves moving one branchinto another. It sounds like you're wanting to use it to rewrite a single branches history onto a new branch. If that's the case, can't you just do it with a series of cherry-picked merges? If so, could provide an example and show how rebase would make it easier? If not, maybe explain what you want to do? -- 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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On 25 December 2012 07:12, Mike Meyer m...@mired.org wrote: for u in $DEVS ADMINS $READERS do # create user name from company mail address, password is PWname. fs new $u $u...@company.com PW$u -R $REPO done for dev in $DEVS do # Set up developers fs cap $dev v -R $REPO done I know I'm probably going to come across as being thick as a whale sandwich here, but ... what is this fs thing? No, it's my bad. fs is my local alias for fossil. I should have replaced expanded it before sending in the examples. This leaves me doubly confused. Neither of these command lines works for me. There is no fossil cap I can see. (Fossil whines about unknown command: cap.) And fossil new doesn't have that command line that I can see. Is this some variant that's not on trunk? (I have a fossil from 2012-12-22's trunk.) -- 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/25/2012 12:44 AM, Michael Richter wrote: This leaves me doubly confused. Neither of these command lines works for me. There is no fossil cap I can see. (Fossil whines about unknown command: cap.) And fossil new doesn't have that command line that I can see. Is this some variant that's not on trunk? (I have a fossil from 2012-12-22's trunk.) The word user is missing from the command line invocations: Usage: fossil user SUBCOMMAND ... ?-R|--repository FILE? Run various subcommands on users of the open repository or of the repository identified by the -R or --repository option. fossil user capabilities USERNAME ?STRING? Query or set the capabilities for user USERNAME fossil user default ?USERNAME? Query or set the default user. The default user is the user for command-line interaction. fossil user list List all users known to the repository fossil user new ?USERNAME? ?CONTACT-INFO? ?PASSWORD? Create a new user in the repository. Users can never be deleted. They can be denied all access but they must continue to exist in the database. fossil user password USERNAME ?PASSWORD? Change the web access password for a user. -- Michael Barrow michael at barrow dot me +1 (408) 782-4249 ___ 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.?
http://facepalm.org I feel stupid. On 26 December 2012 02:23, Michael L. Barrow mlbar...@barrow.me wrote: On 12/25/2012 12:44 AM, Michael Richter wrote: This leaves me doubly confused. Neither of these command lines works for me. There is no fossil cap I can see. (Fossil whines about unknown command: cap.) And fossil new doesn't have that command line that I can see. Is this some variant that's not on trunk? (I have a fossil from 2012-12-22's trunk.) The word user is missing from the command line invocations: Usage: fossil user SUBCOMMAND ... ?-R|--repository FILE? Run various subcommands on users of the open repository or of the repository identified by the -R or --repository option. fossil user capabilities USERNAME ?STRING? Query or set the capabilities for user USERNAME fossil user default ?USERNAME? Query or set the default user. The default user is the user for command-line interaction. fossil user list List all users known to the repository fossil user new ?USERNAME? ?CONTACT-INFO? ?PASSWORD? Create a new user in the repository. Users can never be deleted. They can be denied all access but they must continue to exist in the database. fossil user password USERNAME ?PASSWORD? Change the web access password for a user. -- Michael Barrow michael at barrow dot me +1 (408) 782-4249 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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 19 December 2012 07:33, Mike Meyer m...@mired.org wrote: for u in $DEVS ADMINS $READERS do # create user name from company mail address, password is PWname. fs new $u $u...@company.com PW$u -R $REPO done for dev in $DEVS do # Set up developers fs cap $dev v -R $REPO done I know I'm probably going to come across as being thick as a whale sandwich here, but ... what is this fs thing? ___ 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 Mon, Dec 24, 2012 at 3:39 PM, Michael Richter ttmrich...@gmail.com wrote: On 19 December 2012 07:33, Mike Meyer m...@mired.org wrote: for u in $DEVS ADMINS $READERS do # create user name from company mail address, password is PWname. fs new $u $u...@company.com PW$u -R $REPO done for dev in $DEVS do # Set up developers fs cap $dev v -R $REPO done I know I'm probably going to come across as being thick as a whale sandwich here, but ... what is this fs thing? Fossil, I presume? © -- R K-M-S L ___ 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.?
Michael Richter ttmrich...@gmail.com wrote: On 19 December 2012 07:33, Mike Meyer m...@mired.org wrote: for u in $DEVS ADMINS $READERS do # create user name from company mail address, password is PWname. fs new $u $u...@company.com PW$u -R $REPO done for dev in $DEVS do # Set up developers fs cap $dev v -R $REPO done I know I'm probably going to come across as being thick as a whale sandwich here, but ... what is this fs thing? No, it's my bad. fs is my local alias for fossil. I should have replaced expanded it before sending in the examples. mike -- 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
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Tue, 18 Dec 2012 14:42:34 +0100, Gilles gilles.gana...@free.fr wrote: Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? Thanks everyone for the great feedback. ___ 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 2012-12-18 22:50, j. v. d. hoff wrote: On Tue, 18 Dec 2012 22:29:19 +0100, Mike Meyer m...@mired.org wrote: well-balanced assessment. On Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Well, since no one else has answered publicly, I'll take a stab at it. Fossil has been my goto SCM for over a year now. I use mercurial for things I want to share publicly via GoogleCode (yes, I know about chiselapp, but that's a different discussion). I've used git for client projects for months at a time over the past couple of years, including a week-long project this month. I also have years of experience with subversion, perforce (I am, or was, a PCP), CVS, RCS and a proprietary precursor to perforce. Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? I'd say no. The three are different enough to notice, but whether or not the differences make them a better solution depends more on the organization that's using them than about their fundamental behavior. For example, the major difference is how they handle using rebase to rewrite history. For git, it's a feature. Mercurial provides it as an extension, but the community generally discourages it. Fossil doesn't have it. None of these is universally right, but each is right for some organization. Aside from rebase, the major differences are in things external to their behavior as a SCM, and those tend to be the ones that drive the decision as to which one you want to use if you don't care about rebase. Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work from my recent experience , `autosync' seems to be _the_ feature making the move to DVCS tolerable for some die-hard `svn' users. spaces checked out of the same repository. However, the fossil mail list sees regular though infrequent issues with people who've stumbled over a problem caused by them putting the fossil repo in a work space. could you please elaborate on this? I came to fossil only very recently and, for now, have decided to keep the repo in the checkout directory (just like `hg', say). if I don't won't to have multiple checkouts from the same repo what's potentially bad about this setup? what kind of problems do you have in mind? j. For a single user not having to push/pull merges between multiple work spaces is a win, though you can do that if you want to. For small teams, the self-contained binary means it users fewer resources to deploy if you need a version not in the package manager (or on a system without a package manager). I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. the NetBSD example seems to indicate that fossil's has performance problems for such projects with a massive code base. is this still the state of affairs? not that this would matter for 99.9% of all projects. j. Mercurial: it's strong point is the plugin system. If you need it to do something that's not in the base, there's a good chance there's a plugin that does it. With no extensions, it's a good, vanilla DSCM with a you can't change history philosophy, except for the rollback command that lets you undo the last commit. I use rollback to undo commits that didn't include the right set of files. People regularly show up on the hg users mail list having problems getting it to find the correct versions of all the parts after doing an install or upgrade. Git: I don't like git, because I think mutable history is anathema to what a SCM should be. That said, it's strong point is it's popularity. As a DSCM, what sets it apart is using rebase to rewrite history, and the staging area. The staging area provides the kind of brain fart protection you get from the hg rollback command. On the other hand, I do an empty commit in git because I forgot to set up the staging area far more often than I use the hg rollback command. mike To me, in small projects (1 to 10 persons), the biggest advance of fossil is the use of http, ssh and single binary. If you are in a big company and you need to set up shop then port 80,22 is most of the time open. Asking for firewall changes can be a major problem. Getting access to the scm system can be a major problem to. As to the BSD repositories. I don't think that they represent a normal development work flow. But joerg's work has delivered, important, enhancements to fossil (syncing big repositories) I'm glad he took the time to do that. Better example might be TCL/Tk, sqlite, -- Rene ___ fossil-users mailing list
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Dec 18, 2012, at 14:42 , Gilles wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), I was wondering how Fossil compares to them, for a single user, a small team (up to 20-30), and big teams (thousands). http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? Maybe I missed it skimming the thread, but I didn't notice anyone telling about the big point. There is an attitude difference between Fossil and the other two, which put in database terms would be: Fossil does replication, Git and Mercurial do sharding. The big names have been created for huge teams, where people generally don't want to be overwhelmed by tentative work done by others. Therefore they work in isolation, issuing pull requests once the thing is done. Especially in Git it's popular to compress all the commits to be pulled into one big commit. But the important thing is the isolation. It stands in stark contrast to Fossil's everybody has a copy of everything. In almost all the projects I've seen this is realized by another thing that you don't see in the big names: developers autocommit to a central repository. This renders Fossil basically a modern reincarnation of Subversion, what is appealing to a lot of people. As a bonus you get, a little dumbed down, installation of (distributed) Trac for free with every repository. Kind regards, Remigiusz Modrzejewski ___ 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 Wed, Dec 19, 2012 at 12:06:05PM +0100, Remigiusz Modrzejewski wrote: On Dec 18, 2012, at 14:42 , Gilles wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), I was wondering how Fossil compares to them, for a single user, a small team (up to 20-30), and big teams (thousands). http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? Maybe I missed it skimming the thread, but I didn't notice anyone telling about the big point. There is an attitude difference between Fossil and the other two, which put in database terms would be: Fossil does replication, Git and Mercurial do sharding. The big names have been created for huge teams, where people generally don't want to be overwhelmed by tentative work done by others. Therefore they work in isolation, issuing pull requests once the thing is done. Especially in Git it's popular to compress all the commits to be pulled into one big commit. But the important thing is the isolation. It stands in stark contrast to Fossil's everybody has a copy of everything. In almost all the projects I've seen this is realized by another thing that you don't see in the big names: developers autocommit to a central repository. This renders Fossil basically a modern reincarnation of Subversion, what is appealing to a lot of people. As a bonus you get, a little dumbed down, installation of (distributed) Trac for free with every repository. This is related to having to keep in mind multiple graph HEADs. In fossil, shared with two computers, you have as important references: - computer 1: - checkout - branch head - computer 2 - checkout - branch head But any fossil sync makes branch heads equal in both computers. So, basically, 3 easy points to take into account. In git, you have as important references for two computers: - computer 1 - index - checkout - branch head - remote computer 2 head - computer 2 - index - checkout - branch head - remote computer 1 head There are many commands to propagate from one ref to the other, but I find it very cumbersome (fetch, pull, push, ...). No 'sync' available' to make things easy. Not to mention that it needs also special operations to propagate the 'other' branches to the remote places. Regards, Lluís. ___ 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 Wed, 19 Dec 2012 12:06:05 +0100 Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Dec 18, 2012, at 14:42 , Gilles wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), I was wondering how Fossil compares to them, for a single user, a small team (up to 20-30), and big teams (thousands). http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? Maybe I missed it skimming the thread, but I didn't notice anyone telling about the big point. There is an attitude difference between Fossil and the other two, which put in database terms would be: Fossil does replication, Git and Mercurial do sharding. A lot of the things you discussed have been touched on, but not this central point: The big names have been created for huge teams, where people generally don't want to be overwhelmed by tentative work done by others. Therefore they work in isolation, issuing pull requests once the thing is done. Especially in Git it's popular to compress all the commits to be pulled into one big commit. But the important thing is the isolation. This is a description of workflows, not SCM properties. I've never used that workflow with either git or mercurial (part of my believing that history is sacrosanct). I've pretty much always pushed pulled everything no matter which DSCM I use. In SCM terms, this boils down to fossil not having an easy way to cherry-pick changes to move between repositories. The default push/pull for mercurial is the same as fossil - everything. For git, it's more complicated, but I believe it can be configured so you get the exchange everything behavior if you want it. The bottom line is that if your organization needs fine control over which changes gets exchanged between repositories, fossil isn't for you. At least not yet. It stands in stark contrast to Fossil's everybody has a copy of everything. Except for private branches. There's been some discussion about adding more control over push/pull to fossil, but I don't believe it's happened yet. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ 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 Dec 19, 2012, at 19:56 , Mike Meyer wrote: The big names have been created for huge teams, where people generally don't want to be overwhelmed by tentative work done by others. Therefore they work in isolation, issuing pull requests once the thing is done. Especially in Git it's popular to compress all the commits to be pulled into one big commit. But the important thing is the isolation. This is a description of workflows, not SCM properties. Of course. But bear in mind that the tools are optimized for certain cases that creators had in mind. Fossil was created for a team of (IIRC) three employees of a single company. Git was created for a fuzzy community of some few thousands people. It stands in stark contrast to Fossil's everybody has a copy of everything. Except for private branches. There's been some discussion about adding more control over push/pull to fossil, but I don't believe it's happened yet. Private branches are a pretty recent addition. I believe that the fine grained pushing/pulling will also come sooner or later, once one of folks involved with Fossil feels a need for it. Kind regards, Remigiusz Modrzejewski ___ 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/19/12 22:57, Remigiusz Modrzejewski wrote: It stands in stark contrast to Fossil's everybody has a copy of everything. Except for private branches. There's been some discussion about adding more control over push/pull to fossil, but I don't believe it's happened yet. Private branches are a pretty recent addition. I believe that the fine grained pushing/pulling will also come sooner or later, once one of folks involved with Fossil feels a need for it. Oh, there's definitely a need for it. Like I have mentioned several times before; the full NetBSD fossil repository is unusable for regular source management work. If one could check out individual branches, then perhaps it would become usable (though that's pure speculation at this point). A while back I did some preliminary work to see how one would implement branch-specific pulls, but before moving along with it I (obviously) asked on the mailing-list to see if anyone else was working on it. And at the time, someone was. And last I heard, there had been some significant progress done, but with a few issues to be resolved. Unfortunately, I haven't seen anything on this for quite a while now, so I get a feeling it was abandoned. And currently I don't have the time to pick it up myself. ..the proper solution would be to look into the scalability issues without looking into limited clones -- but there's also a point in limiting the size of the transfer, so the limited clone feels like a better first try project, since it *definitely* solves one issue, and _may_ solve another one. -- Kind regards, Jan Danielsson ___ 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 Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Well, since no one else has answered publicly, I'll take a stab at it. Fossil has been my goto SCM for over a year now. I use mercurial for things I want to share publicly via GoogleCode (yes, I know about chiselapp, but that's a different discussion). I've used git for client projects for months at a time over the past couple of years, including a week-long project this month. I also have years of experience with subversion, perforce (I am, or was, a PCP), CVS, RCS and a proprietary precursor to perforce. Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? I'd say no. The three are different enough to notice, but whether or not the differences make them a better solution depends more on the organization that's using them than about their fundamental behavior. For example, the major difference is how they handle using rebase to rewrite history. For git, it's a feature. Mercurial provides it as an extension, but the community generally discourages it. Fossil doesn't have it. None of these is universally right, but each is right for some organization. Aside from rebase, the major differences are in things external to their behavior as a SCM, and those tend to be the ones that drive the decision as to which one you want to use if you don't care about rebase. Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work spaces checked out of the same repository. However, the fossil mail list sees regular though infrequent issues with people who've stumbled over a problem caused by them putting the fossil repo in a work space. For a single user not having to push/pull merges between multiple work spaces is a win, though you can do that if you want to. For small teams, the self-contained binary means it users fewer resources to deploy if you need a version not in the package manager (or on a system without a package manager). I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. Mercurial: it's strong point is the plugin system. If you need it to do something that's not in the base, there's a good chance there's a plugin that does it. With no extensions, it's a good, vanilla DSCM with a you can't change history philosophy, except for the rollback command that lets you undo the last commit. I use rollback to undo commits that didn't include the right set of files. People regularly show up on the hg users mail list having problems getting it to find the correct versions of all the parts after doing an install or upgrade. Git: I don't like git, because I think mutable history is anathema to what a SCM should be. That said, it's strong point is it's popularity. As a DSCM, what sets it apart is using rebase to rewrite history, and the staging area. The staging area provides the kind of brain fart protection you get from the hg rollback command. On the other hand, I do an empty commit in git because I forgot to set up the staging area far more often than I use the hg rollback command. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ 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 Tue, 18 Dec 2012 22:29:19 +0100, Mike Meyer m...@mired.org wrote: well-balanced assessment. On Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Well, since no one else has answered publicly, I'll take a stab at it. Fossil has been my goto SCM for over a year now. I use mercurial for things I want to share publicly via GoogleCode (yes, I know about chiselapp, but that's a different discussion). I've used git for client projects for months at a time over the past couple of years, including a week-long project this month. I also have years of experience with subversion, perforce (I am, or was, a PCP), CVS, RCS and a proprietary precursor to perforce. Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? I'd say no. The three are different enough to notice, but whether or not the differences make them a better solution depends more on the organization that's using them than about their fundamental behavior. For example, the major difference is how they handle using rebase to rewrite history. For git, it's a feature. Mercurial provides it as an extension, but the community generally discourages it. Fossil doesn't have it. None of these is universally right, but each is right for some organization. Aside from rebase, the major differences are in things external to their behavior as a SCM, and those tend to be the ones that drive the decision as to which one you want to use if you don't care about rebase. Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work from my recent experience , `autosync' seems to be _the_ feature making the move to DVCS tolerable for some die-hard `svn' users. spaces checked out of the same repository. However, the fossil mail list sees regular though infrequent issues with people who've stumbled over a problem caused by them putting the fossil repo in a work space. could you please elaborate on this? I came to fossil only very recently and, for now, have decided to keep the repo in the checkout directory (just like `hg', say). if I don't won't to have multiple checkouts from the same repo what's potentially bad about this setup? what kind of problems do you have in mind? j. For a single user not having to push/pull merges between multiple work spaces is a win, though you can do that if you want to. For small teams, the self-contained binary means it users fewer resources to deploy if you need a version not in the package manager (or on a system without a package manager). I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. the NetBSD example seems to indicate that fossil's has performance problems for such projects with a massive code base. is this still the state of affairs? not that this would matter for 99.9% of all projects. j. Mercurial: it's strong point is the plugin system. If you need it to do something that's not in the base, there's a good chance there's a plugin that does it. With no extensions, it's a good, vanilla DSCM with a you can't change history philosophy, except for the rollback command that lets you undo the last commit. I use rollback to undo commits that didn't include the right set of files. People regularly show up on the hg users mail list having problems getting it to find the correct versions of all the parts after doing an install or upgrade. Git: I don't like git, because I think mutable history is anathema to what a SCM should be. That said, it's strong point is it's popularity. As a DSCM, what sets it apart is using rebase to rewrite history, and the staging area. The staging area provides the kind of brain fart protection you get from the hg rollback command. On the other hand, I do an empty commit in git because I forgot to set up the staging area far more often than I use the hg rollback command. mike -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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/18/12 22:29, Mike Meyer wrote: [---] I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. I don't think large team is a problem, apart from the manual work required in setting up users. I did some work a while back gluing together fossil with a security middleware which has an integrated identity manager. It reused the identity manager to configure fossil server instances. I did some quick'n'dirty hacks; like opening up the repository via libsqlite and manipulated the databases directly, which didn't feel all too excellent. (Though the whole thing was a proof-of-concept and something to demo, more than anything else). My primary experience from that project was that there are some areas where fossil could be enhanced to allow easier integration with identity managers, which could ease user-management for very large teams. The biggest problem I have encountered with fossil is with regards to scalability. Anyone who has tried to use the NetBSD fossil repository knows it's a pretty painful experience. With that said, I came to fossil from bazaar which I abandoned because it had scalability issues (which were even worse), so it's not an exclusive fossil-problem. (git isn't affected by this though, but it's noteworthy that the NetBSD project on github is (was?) imported from the fossil NetBSD repository). -- Kind regards, Jan Danielsson ___ 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 Tue, 18 Dec 2012 23:50:17 +0100, Jan Danielsson
jan.m.daniels...@gmail.com wrote:
On 12/18/12 22:29, Mike Meyer wrote:
[---]
I don't know of anyone using it for a large team. I don't know of any
reason not to, except for the risk of being the first to try that.
I don't think large team is a problem, apart from the manual work
required in setting up users. I did some work a while back gluing
together fossil with a security middleware which has an integrated
identity manager. It reused the identity manager to configure fossil
server instances. I did some quick'n'dirty hacks; like opening up the
repository via libsqlite and manipulated the databases directly, which
didn't feel all too excellent. (Though the whole thing was a
proof-of-concept and something to demo, more than anything else).
My primary experience from that project was that there are some areas
where fossil could be enhanced to allow easier integration with identity
managers, which could ease user-management for very large teams.
even for small teams I'd prefer to be able to do user management (easily)
from the command line.
so I don't overlook anything if I presume that user management currently
_needs_ to be done
via the web gui? some fossil command like
fossil adduser {basic configuration options go here} user1, user2, ...
would be nice to have. fine-tuning might be delegated to the webinterface
but
the basic things (adding admin users, development users etc) should be
possible otherwise.
The biggest problem I have encountered with fossil is with regards to
scalability. Anyone who has tried to use the NetBSD fossil repository
knows it's a pretty painful experience.
With that said, I came to fossil from bazaar which I abandoned
because it had scalability issues (which were even worse), so it's not
an exclusive fossil-problem. (git isn't affected by this though, but
it's noteworthy that the NetBSD project on github is (was?) imported
from the fossil NetBSD repository).
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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/18/12 22:50, j. v. d. hoff wrote: the NetBSD example seems to indicate that fossil's has performance problems for such projects with a massive code base. is this still the state of affairs? Last time I used my NetBSD fossil repository, it was still pretty much unusable. I don't think anything has changed on that front since then. I have a pretty high-powered PC, and it still takes a few hours for rebuilds. For a friend of mine, who has a Pentium3-class system, pulling latest changes and rebuilding the NetBSD fossil repository takes around ~24h each time. not that this would matter for 99.9% of all projects. Definitely true. -- Kind regards, Jan Danielsson ___ 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 Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer m...@mired.org wrote: I don't do that (I keep all my fossil repositories in ~/repos), so haven't paid close attention to the issues. The big one seems to be accidentally trying to add the repository to itself. The resulting checkin never terminates. I also recall problems with Windows (something else I don't use) where the solution was to move the repository out of the work space. Maybe the people who helped solve the problems can comment on this? Or maybe my skimming of such problems has led me to a false conclusion. I think all these problems are fixed and that it is safe to keep the repo in the check-out directory. -- D. Richard Hipp d...@sqlite.org ___ 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 Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer m...@mired.org wrote: I don't do that (I keep all my fossil repositories in ~/repos), so haven't paid close attention to the issues. The big one seems to be accidentally trying to add the repository to itself. The resulting checkin never terminates. I also recall problems with Windows (something else I don't use) where the solution was to move the repository out of the work space. Maybe the people who helped solve the problems can comment on this? Or maybe my skimming of such problems has led me to a false conclusion. I think all these problems are fixed and that it is safe to keep the repo in the check-out directory. relieved to here that, thanks. are there any other valid arguments (beyond matter of taste things like I want to separate the repo from the checkout and facilitating backups by putting all repos in a single place) which make it unwise to keep the repo within the checkout? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 Wed, 19 Dec 2012 00:02:11 +0100
j. v. d. hoff veedeeh...@googlemail.com wrote:
even for small teams I'd prefer to be able to do user management (easily)
from the command line.
so I don't overlook anything if I presume that user management currently
_needs_ to be done
via the web gui?
Nope, it doesn't.
some fossil command like
fossil adduser {basic configuration options go here} user1, user2, ...
It's not quite that easy - you have to mangle one user at a time, and
user creation is it's own command.
would be nice to have. fine-tuning might be delegated to the webinterface
but
the basic things (adding admin users, development users etc) should be
possible otherwise.
I'd say it is. It could be better, but it's there. I generally wind up
running a shell loop:
for u in $DEVS ADMINS $READERS
do
# create user name from company mail address, password is PWname.
fs new $u $u...@company.com PW$u -R $REPO
done
for dev in $DEVS
do
# Set up developers
fs cap $dev v -R $REPO
done
Setting up new users in mass doesn't make a lot of sense - you
probably want to set contact information and passwords separately
anyway. Setting permissions (capabilities) for a group would be a nice
enhancement.
mike
--
Mike Meyer m...@mired.org http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
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.?
thanks for clarifying this. gonna check the help pages before spamming the
list again
On Wed, 19 Dec 2012 00:33:29 +0100, Mike Meyer m...@mired.org wrote:
On Wed, 19 Dec 2012 00:02:11 +0100
j. v. d. hoff veedeeh...@googlemail.com wrote:
even for small teams I'd prefer to be able to do user management
(easily)
from the command line.
so I don't overlook anything if I presume that user management currently
_needs_ to be done
via the web gui?
Nope, it doesn't.
some fossil command like
fossil adduser {basic configuration options go here} user1, user2, ...
It's not quite that easy - you have to mangle one user at a time, and
user creation is it's own command.
would be nice to have. fine-tuning might be delegated to the
webinterface
but
the basic things (adding admin users, development users etc) should be
possible otherwise.
I'd say it is. It could be better, but it's there. I generally wind up
running a shell loop:
for u in $DEVS ADMINS $READERS
do
# create user name from company mail address, password is PWname.
fs new $u $u...@company.com PW$u -R $REPO
done
for dev in $DEVS
do
# Set up developers
fs cap $dev v -R $REPO
done
Setting up new users in mass doesn't make a lot of sense - you
probably want to set contact information and passwords separately
anyway. Setting permissions (capabilities) for a group would be a nice
enhancement.
mike
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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 Tue, Dec 18, 2012 at 6:28 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer m...@mired.org wrote: I don't do that (I keep all my fossil repositories in ~/repos), so haven't paid close attention to the issues. The big one seems to be accidentally trying to add the repository to itself. The resulting checkin never terminates. I also recall problems with Windows (something else I don't use) where the solution was to move the repository out of the work space. Maybe the people who helped solve the problems can comment on this? Or maybe my skimming of such problems has led me to a false conclusion. I think all these problems are fixed and that it is safe to keep the repo in the check-out directory. relieved to here that, thanks. are there any other valid arguments (beyond matter of taste things like I want to separate the repo from the checkout and facilitating backups by putting all repos in a single place) which make it unwise to keep the repo within the checkout? Capabilities to work on multiple different checkout associated with different branch/revision/tag using the same repo file. Example: - $ mkdir checkout $ cd checkout ## a checkout for the trunk $ fossil open ~/repos/a_repo.fossil ... $ cd .. $ mkdir checkout_some_branch $ cd checkout_some_branch ## a checkout for the branch some_branch using the same repo file. $ fossil open ~/repos/a_repo.fossil some_branch - That is a killer feature for me. This is impossible to do with git or hg. Eg. with git, each checkout have to be a different clone with their own .git directory which contain the whole history. Regards -- Martin G. ___ 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 Wed, 19 Dec 2012 01:04:19 +0100, Martin Gagnon eme...@gmail.com wrote: On Tue, Dec 18, 2012 at 6:28 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer m...@mired.org wrote: I don't do that (I keep all my fossil repositories in ~/repos), so haven't paid close attention to the issues. The big one seems to be accidentally trying to add the repository to itself. The resulting checkin never terminates. I also recall problems with Windows (something else I don't use) where the solution was to move the repository out of the work space. Maybe the people who helped solve the problems can comment on this? Or maybe my skimming of such problems has led me to a false conclusion. I think all these problems are fixed and that it is safe to keep the repo in the check-out directory. relieved to here that, thanks. are there any other valid arguments (beyond matter of taste things like I want to separate the repo from the checkout and facilitating backups by putting all repos in a single place) which make it unwise to keep the repo within the checkout? Capabilities to work on multiple different checkout associated with different branch/revision/tag using the same repo file. Example: - $ mkdir checkout $ cd checkout ## a checkout for the trunk $ fossil open ~/repos/a_repo.fossil ... $ cd .. $ mkdir checkout_some_branch $ cd checkout_some_branch ## a checkout for the branch some_branch using the same repo file. $ fossil open ~/repos/a_repo.fossil some_branch - That is a killer feature for me. This is impossible to do with git or hg. Eg. with git, each checkout have to be a different clone with their own .git directory which contain the whole history. OK, I see what you mean, but this wouldn't be important for me AFAICS. actually I don't see any real advantage of this approach compared to simply updating to the respective branches in turn in order to work on them. so (for me) this would fall under the matter of taste category (which still means it's nice that it can be done). j. Regards -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 Tue, Dec 18, 2012 at 03:29:19PM -0600, Mike Meyer wrote: On Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work spaces checked out of the same repository. Monotone also works as a self-contained binary (written in C++, with more library dependencies, but all can be statically linked if desired). And it has a centralised database, from where you can have multiple checkouts and multiple repositories. And it has a very powerful tagging mechanism. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
