Re: [fossil-users] comparison with Git
On 12 October 2012 00:21, Ron Wilson ronw.m...@gmail.com wrote: I would think that rebasing would do the same number of merges, just that it automates those merges. Yes, that's what rebasing is. Also rebasing based development process keeps branches shallow and the case with commits interleaved wildly does not really happen. Note that you rebase against upstream that is independent of your branch so the case when you merge upstream into your private branch does not really happen. Upstream can at times include some of your commits which are then eliminated from your branch on rebase because they are already included in the upstream branch. The thing what rebase gives you over single merge are readable patches that are either accepted and included at the tip of upstream or can be applied on top af a release tarball or can be basis for furthere development. With single merge you get a huge merge commit which can be used the same way except it makes no sense on its own, can't be separated into incremental changes that make sense, and when you base further developmnet on top of it (eg. the merge was rejected by upstream) you get those long branches that plug into ancient project history with wildly interweaved commits. 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] comparison with Git
On 9/14/12, Michal Suchanek hramr...@gmail.com wrote: On 14 September 2012 20:10, Jacek Cała jacek.c...@gmail.com wrote: I don't understand. Without rebase you just merge the other branch (D-E-F) to your cloned and updated repo (X-Y-Z), resolve any conflicts and end up in the same point, ok with one more commit which is the merge of F to Z. Except with a merge of F-Z you get a single commit which is often huge patch of no value on its own. To understand what it does you have to review the whole branch before the merge possibly with numerous intermediate merges. What times did D, E and F take place relative to X, Y and Z? Simplest case, merge X into F, creating X', then commit X' as child of F. Then Y into X' and Z into Y', leaving a commit history of A, B, C, D, E, F, X', Y', Z'. Alternating case: Merge X into D, commit X'. Then Y into (E into X'), commit Y'. Then Z into (F into Y'), commit Z'. Which is 2 extra merges. I think this would be the worst case without involving reordering. For the given example of Z being a fix to X: Merge (Z into X) into D, commit X'. Then Y into ((F into E) into X'), commit Y'. Still 2 extra merges. (If you don't squash Z into X, then is same as the previous case except swap Y and Z.) I would think that rebasing would do the same number of merges, just that it automates those merges. I think a rebase script that uses Fossil would need to: List new commits in time order Allow user to alter order and specify any desired squashing. Perform merges as needed, pausing as needed to allow user to resolve conflicts. How close am I to what git rebase would do? ___ 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] comparison with Git
On Oct 9, 2012, at 20:44 , Eric wrote: On Tue, 9 Oct 2012 12:19:59 +0200, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: But who would prevent a cow worker from using them? Cow worker Reference to the Dilbert comics... The idea is that, especially in corporate environments, you'll at some point end up working with people who'll be, in your eyes, highly defective. Unless you're always in exclusive control of hiring, you'd better think of mechanical ways to enforce your vision of the project. Actually... No. Fossil, with it's monolithic single-app design, is relatively hard to both extend and embed. Actually there are two kinds of people in the world, those who expect something to do whatever they think it should, and those who look at what it is designed to do, and how it is designed to be used, and then either use it accordingly or find something else. Of course success in extending or embedding depends on the level of available skill in awk or Perl or Expect or whatever. Remember that the target end-user for Fossil is a developer! Yeah, you pretty nailed it. A perfect explanation why Fossil's integrations into various IDE's, GUI front-ends and other integrations are so popular. I may be OK with CLI, but it already bit me a few times: I can not use Fossil in my day job, because there's no Eclipse plugin (apart from that, the team said whatever, we're free to start new projects in whatever VCS that Eclipse supports). But don't say it's easy to extend by writing a separate client or ipc-ing to this one... Why not, it's a perfectly acceptable technique. Acceptable, yes, in some circumstances. But compare: open3 a process and parse the output (is it even guaranteed to be stable?) to a function call... 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] comparison with Git
Remigiusz Modrzejewski l...@maxnet.org.pl wrote: Actually... No. Fossil, with it's monolithic single-app design, is relatively hard to both extend and embed. Actually there are two kinds of people in the world, those who expect something to do whatever they think it should, and those who look at what it is designed to do, and how it is designed to be used, and then either use it accordingly or find something else. Of course success in extending or embedding depends on the level of available skill in awk or Perl or Expect or whatever. Remember that the target end-user for Fossil is a developer! Yeah, you pretty nailed it. A perfect explanation why Fossil's integrations into various IDE's, GUI front-ends and other integrations are so popular. I may be OK with CLI, but it already bit me a few times: I can not use Fossil in my day job, because there's no Eclipse plugin (apart from that, the team said whatever, we're free to start new projects in whatever VCS that Eclipse supports). Well, the lack of an in-binary API certainly isn't the reason there's not an Eclipse plugin. The Eclipse license is incompatible with the GPL, so any scm that's GPL'ed (*cough* git *cough*) isn't linked with Eclipse, but probably uses a process API. The mercurial folks have a Python API, but strongly recommend that you just run hg, as they work to keep that compatible between versions, and make no such effort with the Python API. It seems to have a plugin for most GUI IDEs. But don't say it's easy to extend by writing a separate client or ipc-ing to this one... Why not, it's a perfectly acceptable technique. Acceptable, yes, in some circumstances. In *far* more circumstances than linking to a library is acceptable. But compare: open3 a process and parse the output (is it even guaranteed to be stable?) to a function call... Well, an API - no matter how it's implemented - is only as stable as the developers make it. Whether or not you break an API when you upgrade the provider depends *far* more on the developers than whether they chose to provide it via an executable or a shared library. And if you're going to compare them, compare the entire process: One is - well, open the executable and parse the output. The other is: select a language that can be coerced into linking with the library you want to use, write or find a wrapper if it's required that will translate between calling conventions and data types, load the shared library and wrapper code, and *now* you can call your wrapper to get and convert the data. Oh, and if you want to let someone else use your plugin, you have to make sure all the licenses involved are compatible. Nuts, after writing the Python wrapper for the perforce C++ library, I wound up rewriting it for our Windows group to use the p4 command instead of the library, because that was easier cheaper than buying the C++ compiler used to build the Perforce Windows binary and porting Python to it. But it made our support scripts portable across Windows and Unix. -- 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] comparison with Git
On Oct 10, 2012, at 14:28 , Mike Meyer wrote: Well, the lack of an in-binary API certainly isn't the reason there's not an Eclipse plugin. The Eclipse license is incompatible with the GPL, so any scm that's GPL'ed (*cough* git *cough*) isn't linked with Eclipse, but probably uses a process API. But Fossil is not GPL. It would make perfect sense to link it wherever you'd like. For Git, it seems that it's primary implementation is a bit too messy for most big projects, so they simply reimplement it. Eclipse's implementation is called JGit. And it does provide a reasonably stable Java API, used by a few projects. On the other hand, Fossil's implementation is (apart from the regular forking) quite nice. I'd bet you a beer that once the JSON API is finished (in my already outlined understanding), it will be used by some useful projects. 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] comparison with Git
Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Oct 10, 2012, at 14:28 , Mike Meyer wrote: Well, the lack of an in-binary API certainly isn't the reason there's not an Eclipse plugin. The Eclipse license is incompatible with the GPL, so any scm that's GPL'ed (*cough* git *cough*) isn't linked with Eclipse, but probably uses a process API. But Fossil is not GPL. It would make perfect sense to link it wherever you'd like. For Git, it seems that it's primary implementation is a bit too messy for most big projects, so they simply reimplement it. Eclipse's implementation is called JGit. And it does provide a reasonably stable Java API, used by a few projects. Yeah, the *reimplimented* git in order to avoid the language and license issues of using the git code directly. That pretty much kills the argument that having to invoke fossil as a command is to much work! On the other hand, Fossil's implementation is (apart from the regular forking) quite nice. I'd bet you a beer that once the JSON API is finished (in my already outlined understanding), it will be used by some useful projects. No bet, because I agree with you. Except that I consider using modern concurrency technics a plus, not a minus. -- 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] comparison with Git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/09/2012 11:19 AM, Remigiusz Modrzejewski wrote: Actually... No. Fossil, with it's monolithic single-app design, is relatively hard to both extend and embed. Also, seeing how Natacha's attempts at providing a much-requested feature were ignored, it can be hard to influence. Is it time to fork Fossil? Richard has his own priorities, and if there's enough people who'd like to see Fossil go in a different direction, it would be perfectly honorouable for a fork that served different priorities to form in an amicable manner. As much as possible should be contributed to the original Fossil and then pulled into the fork, but the fork can accept direct contributions that Original Fossil won't. 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/ iEYEARECAAYFAlB0AVgACgkQRgz/WHNxCGr2EQCfd0+wJw2Ox5kHNEzZuFJO96me vEwAniXvrCjgaD5DgBVOEhhibnQIcOhD =QgoL -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] comparison with Git
Remigiusz Modrzejewski wrote: Actually... No. Fossil, with it's monolithic single-app design, is relatively hard to both extend and embed. I strongly disagree with this statement. Fossil is very extensible in the classic Unix sense, by building command lines and parsing the resulting output. Also, much work has been done, by myself and others, to make Fossil extensible using Tcl. Finally, Stephan Beal has done quiet a lot of work to make the JSON API a reality, which enables quite a few useful extensibility scenarios. Also, seeing how Natacha's attempts at providing a much-requested feature were ignored, it can be hard to influence. I very strongly disagree with this statement because I can prove it is inaccurate. She has not been ignored. I have been assigned by Richard to help with integrating her work into Fossil and have been in direct contact with her. Also, you may notice the markdown branch in the official repository as of October 3rd, 2012. -- Joe Mistachkin ___ 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] comparison with Git
On Oct 9, 2012, at 13:30 , Joe Mistachkin wrote: Remigiusz Modrzejewski wrote: Actually... No. Fossil, with it's monolithic single-app design, is relatively hard to both extend and embed. I strongly disagree with this statement. Fossil is very extensible in the classic Unix sense, by building command lines and parsing the resulting output. We both know how this compares to having an actual API... Also, much work has been done, by myself and others, to make Fossil extensible using Tcl. So, is it finally possible to script pre-/post- commit hooks? Finally, Stephan Beal has done quiet a lot of work to make the JSON API a reality, which enables quite a few useful extensibility scenarios. Yes, but his work would be much easier if it wasn't an afterthought. Plus, this is still a work in progress. Only once it is finished, and by that apart being functional I mean included in the official build and documentation, we can finally say that there is a Fossil API. She has not been ignored. I have been assigned by Richard to help with integrating her work into Fossil and have been in direct contact with her. Also, you may notice the markdown branch in the official repository as of October 3rd, 2012. Oh, I missed that part. That's happy news to me :) 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] comparison with Git
On Oct 9, 2012, at 16:36 , Joe Mistachkin wrote: Remigiusz Modrzejewski wrote: So, is it finally possible to script pre-/post- commit hooks? More or less: http://www.fossil-scm.org/index.html/artifact?ci=trunkfilename=src/xfer.cl n=1201-1205 The key is that these are actually post-transfer scripts. It is up to the called script to determine how many commits, if any, have been done since it was last called. I have a working proof-of-concept Tcl script on a private repository that does this and sends mail via SMTP if a commit is detected. The real expressive power here comes from having Tcl enabled at compile-time (and via the runtime setting) and being able to seamlessly invoke it from TH1. That's nice. I guess I'll try to use it in the following months (for continuous integration). But it's still impossible to obtain policing with that. Like, refusing to receive a push if some commit was not properly signed. This would be a pretty useful thing that's long time possible in the competing products. Thankfully I will not need that for a long time and hope Fossil gets it before that. 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] comparison with Git
On Fri, Sep 14, 2012 at 10:48 AM, Lluís Batlle i Rossell vi...@viric.name wrote: I think that the git 'rebase' history rewriting could be stated different. Maybe the graph could be altered with fossil cards, the same way commit logs are changed. Then, graph reworking would not imply history rewriting (and thus history loss) as git does. git rebase is one of git's various app killers. And no, rebase need not equal history re-writing. When I rebase I almost always do it in a branch new branch that starts with the same HEAD as the previous one. I use rebase for: - splitting commits - merging commits into one (squash, not three-way merge) - amend commit messages - re-order commits I do such things for either a) cleanup (I want the master branch to be as clean as possible) b) or in response to code review comments from an upstream I'll be contributing commits to Being able to do (b) is critical for some upstreams I contribute to. Since I can't write perfect code the first time I absolutely need rebase. Again, rebase need not be seen as destructive: ideally git rebase should require a new branch name argument and it should make the new branch refer to the rebased contents while leaving the previous branch alone. 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] comparison with Git
On Thu, Sep 13, 2012 at 04:28:00PM -0700, Russ Paielli wrote: OK, so apparently I misunderstood in thinking that the serverless, zero-administration claim applies to Fossil. Thanks for the clarification. If it were true, and if it distinguished Fossil from Git, I would have used it in my advocacy of Fossil. I'd say that this aspect (tentative zero-administration) would only be of interest to persons who routinely perform the said administration (possibly at their $dayjob), and users (in the sense not system administrators) are usually sold on other aspects of software. I am sold on the idea that Fossil is superior to Git on the basis of simplicity alone. Than again, I am currently a minimal Fossil user. Being an aero engineer rather than a developer per se, I'd rather not spend time learning Git. The problem, as I have said before here, is that Git seems to be the de facto standard for open-source software. So not knowing Git essentially shuts you out of most open source. But as I understand, you're not a programmer (at least not a hard-core type who just seek fun in learning the next big thing and all that), so not learning Git to ride *this* wave looks to be perfectly okay for you. On the other hand, Git is not *that* hard to learn basic concepts, really. And it has external tools providing fancy GUIs, if needed. In addition, I feed slightly uncomfortable forcing someone who already knows Git to learn Fossil in order to work on my project. But maybe I shouldn't worry about that. I think it highly depends on the person(s) you're considering as a possible collaborator(s) for your project. I'd say that learning Fossil is not hard for anyone having decent knowledge of another DVCS system. Another possible argument which might be used to convince someone is that it's good to leave one's comfort zone from time to time; this applies not only to social interactions but to programming languages and software tools as well (and, I suppose, to many other fields I'm just not familiar with). You could also assess if your project would benefit from using wiki/built-in documentation editor and issue tracker; if so, Fossil might have a huge head start compared to other tools for you, and this could be used when advocating its usage. ___ 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] comparison with Git
On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On the other hand, Git is not *that* hard to learn basic concepts, really. And it has external tools providing fancy GUIs, if needed. My argument goes like this: Every developer has a fixed number of brain cycles to use on any given day. Some of this brain-energy must be expended for overhead, such as finding ones way to the coffee machine, or operating the version-control system (VCS). The fewer brain-cycles one has to spend on the overhead functions, the more there are available for us in writing code. The goal of Fossil is to require fewer brain-cycles. Fossil isn't perfect. I'm sure there are things that can be done so that it requires less effort. But I believe it is better than monotone, bzr, or hg, and way better than git. Of all of the VCSes out there today, surely Git requires more daily brain-cycles than any other. I'm not talking about just the learning-curve here. Git requires more thought and attention even after you know it well. And that extra thought and attention that you devote toward operating Git could be better spent working on your project. -- 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] comparison with Git
On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote: On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On the other hand, Git is not *that* hard to learn basic concepts, really. And it has external tools providing fancy GUIs, if needed. My argument goes like this: Every developer has a fixed number of brain cycles to use on any given day. Some of this brain-energy must be expended for overhead, such as finding ones way to the coffee machine, or operating the version-control system (VCS). The fewer brain-cycles one has to spend on the overhead functions, the more there are available for us in writing code. The goal of Fossil is to require fewer brain-cycles. Fossil isn't perfect. I'm sure there are things that can be done so that it requires less effort. But I believe it is better than monotone, bzr, or hg, and way better than git. Of all of the VCSes out there today, surely Git requires more daily brain-cycles than any other. I'm not talking about just the learning-curve here. Git requires more thought and attention even after you know it well. And that extra thought and attention that you devote toward operating Git could be better spent working on your project. Interesting idea, this of brain cycles. :) I also find git particularly difficult. In the case of having two checkouts in two computers, it ends up scaling to 4 heads: local and remote head in each computer. And all operations (merge, fetch, ...) work updating references between those *4* heads, instead of 2. I find that with two checkouts, I shouldn't need graph operations between 4 heads. For me, it means double 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] comparison with Git
On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote: On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: Of all of the VCSes out there today, surely Git requires more daily brain-cycles than any other. I'm not talking about just the learning-curve here. Git requires more thought and attention even after you know it well. And that extra thought and attention that you devote toward operating Git could be better spent working on your project. BTW, I've the impression that some people feel like they do something useful, just because they do something. That's how I see that some people enjoy using git. Like people who solves sudoku. Nevertheless, there are some kind of projects where git or monotone can have an advantage; for example, there is more fine grained control of what you share and what not of your graph, into a remote repository. ___ 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] comparison with Git
Hello, On 14 September 2012 14:43, Lluís Batlle i Rossell vi...@viric.name wrote: On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote: On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: Of all of the VCSes out there today, surely Git requires more daily brain-cycles than any other. I'm not talking about just the learning-curve here. Git requires more thought and attention even after you know it well. And that extra thought and attention that you devote toward operating Git could be better spent working on your project. BTW, I've the impression that some people feel like they do something useful, just because they do something. That's how I see that some people enjoy using git. Like people who solves sudoku. I find that git and hg require more thought in different areas. I don't use fossil much but I would lump it together with hg here due to the stress on immutable history. The thing to which promoters of immutable history are blind is that while exact history record of development of particular feature might be interesting and educational it is not the primary purpose if VCS. For start the VCS history is necessarily imperfect record because you have only certain points in time recorded - the commits. What happens in between might be equally or even more interesting and educational but is not seen in the record. Second the purpose of VCS is not to record exact history to the tiniest detail but to record change(set)s to the code that are somewhat self-contained and can be understood on their own. This may be so that you can later go back and see what you did or so that you can take these changesets and send them to an upstream/peer developer for review, and it makes sense to them. And the makes *sense* is the crucial part here. When you learn maths you often hear something like this theorem AB was first proven by XY using method CD but we will today prove it using a much shorter and easier to understand method EF. Similarly, when implementing a feature into a piece of software the real history and the logical changes that make sense and are easy to review are often quite different things. With git you get powerful history rewriting commands. The drawback is that you have to be careful to not lose anything important in the rewriting. With hg and fossil rewriting is hard to non-existent and you end up with a jungle of commits that is hard to navigate and without tools to adequately manage such jungle. So for me the cycles for managing source with git and with hg/fossil are spent in different places but I would not say that one requires less than the other. The hg manual recommends to use one I/O repository to which you pull from usptream and push finished features and development repositories(s) that contain the jungle of unfinished features that you can just blow away when the feature is finished. Git allows managing that in one repo but you need to remember doing backups before attempting any drastic surgery on it. Not that you don't need backups for other reasons, anyway. 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] comparison with Git
On Fri, Sep 14, 2012 at 9:35 AM, Michal Suchanek hramr...@gmail.com wrote: The thing to which promoters of immutable history are blind is that while exact history record of development of particular feature might be interesting and educational it is not the primary purpose if VCS. The exact preservation of history is considered best practice for high-reliability and safety-critical systems. Fossil, for example, was designed to meet the VCS requirements of DO-178B level A. (Ref: http://en.wikipedia.org/wiki/DO-178B) You might not think that exact preservation of history is one of the primary purposes of VCS, but not every project manager thinks exactly like you. -- 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] comparison with Git
On Fri, Sep 14, 2012 at 8:35 AM, Michal Suchanek hramr...@gmail.com wrote: The thing to which promoters of immutable history are blind is that while exact history record of development of particular feature might be interesting and educational it is not the primary purpose if VCS. That depends on what you're using the VCS for. Given that I use the VCS to capture an exact history of the change sets I thought were worth committing, that *is* it's primary purpose. And the makes *sense* is the crucial part here. When you learn maths you often hear something like this theorem AB was first proven by XY using method CD but we will today prove it using a much shorter and easier to understand method EF. Similarly, when implementing a feature into a piece of software the real history and the logical changes that make sense and are easy to review are often quite different things. True. And which of the two things you are interested in will depend on *why* you're using the VCS. For me, the *real* history is the important thing. Yeah, I may record having done something the wrong way, but having a record of the wrong way and the results of doing it that way is *also* important. Others can either skip doing that exploration, or look through the history to see *why* that way is wrong. With git you get powerful history rewriting commands. The drawback is that you have to be careful to not lose anything important in the rewriting. Your view matches the common view of git users, which follow the Linux project and treat the repository as part of the public face of the project. If you look at things that way, not being able to edit the repository history makes about as much sense as not being able to edit the web site. I see the VCS as part of the internal project documentation. Being allowed to edit it makes as much sense as editing generated API documentation to change function signatures. 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] comparison with Git
On 14 September 2012 15:52, Richard Hipp d...@sqlite.org wrote: On Fri, Sep 14, 2012 at 9:35 AM, Michal Suchanek hramr...@gmail.com wrote: The thing to which promoters of immutable history are blind is that while exact history record of development of particular feature might be interesting and educational it is not the primary purpose if VCS. The exact preservation of history is considered best practice for high-reliability and safety-critical systems. Fossil, for example, was designed to meet the VCS requirements of DO-178B level A. (Ref: http://en.wikipedia.org/wiki/DO-178B) You might not think that exact preservation of history is one of the primary purposes of VCS, but not every project manager thinks exactly like you. I don't think that's a bad goal. The failure I see is inadequate tools for working with the resulting commit jungle. And if you were really obstinate about that then fossil fails in that it does not record *every* change, it requires explicit commits. 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] comparison with Git
Hi all, My two cents: I like phrase *commit jungle* and sometimes would like to revert some commits or re-commit things a bit different. I also suppose that it is not that rare when people commit something by mistake or something which has not been tested enough. On the other hand my gut feeling is that (apart from what was said before) changing history is just bad and should be avoided. Perhaps the tooling you are talking about is just a filtered commit view. I mean if fossil allowed users to attach a tag (e.g. private) to commits to say that they aren't visible in the timeline by default, we could avoid the jungle and also keep exact history by giving users a full view option where everything is visible (as it is shown currently). Also the thing is that some commits tend to be more important than others (you usually tag somehow like version X.Y). But in this context it's perhaps better to say that some commits are much less important than others (e.g. correcting a spelling mistake in the comments). I think that the filtered view would allow to hide these. Michal would that be enough for you to match with the git rewriting option (which I'm not aware of)? Cheers, Jacek 2012/9/14 Michal Suchanek hramr...@gmail.com: On 14 September 2012 15:52, Richard Hipp d...@sqlite.org wrote: On Fri, Sep 14, 2012 at 9:35 AM, Michal Suchanek hramr...@gmail.com wrote: The thing to which promoters of immutable history are blind is that while exact history record of development of particular feature might be interesting and educational it is not the primary purpose if VCS. The exact preservation of history is considered best practice for high-reliability and safety-critical systems. Fossil, for example, was designed to meet the VCS requirements of DO-178B level A. (Ref: http://en.wikipedia.org/wiki/DO-178B) You might not think that exact preservation of history is one of the primary purposes of VCS, but not every project manager thinks exactly like you. I don't think that's a bad goal. The failure I see is inadequate tools for working with the resulting commit jungle. And if you were really obstinate about that then fossil fails in that it does not record *every* change, it requires explicit commits. Thanks Michal ___ 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] comparison with Git
On 14 September 2012 16:57, Jacek Cała jacek.c...@gmail.com wrote: Hi all, My two cents: I like phrase *commit jungle* and sometimes would like to revert some commits or re-commit things a bit different. I also suppose that it is not that rare when people commit something by mistake or something which has not been tested enough. On the other hand my gut feeling is that (apart from what was said before) changing history is just bad and should be avoided. The commit jungle the result of exactly that - reverting some commits or recommitting with the old commits staying around in many short stumped branches. Perhaps the tooling you are talking about is just a filtered commit view. I mean if fossil allowed users to attach a tag (e.g. private) to commits to say that they aren't visible in the timeline by default, we could avoid the jungle and also keep exact history by giving users a full view option where everything is visible (as it is shown currently). Also the thing is that some commits tend to be more important than others (you usually tag somehow like version X.Y). But in this context it's perhaps better to say that some commits are much less important than others (e.g. correcting a spelling mistake in the comments). I think that the filtered view would allow to hide these. Michal would that be enough for you to match with the git rewriting option (which I'm not aware of)? Indeed, it's about good tools for filtering out unwanted commits and good tutorial for using those tools. Not only for viewing but also for pushing/pulling. Or perhaps good view filters would make pushing lots of junk less of an issue. 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] comparison with Git
On Fri, Sep 14, 2012 at 05:08:53PM +0200, Michal Suchanek wrote: On 14 September 2012 16:57, Jacek Cała jacek.c...@gmail.com wrote: Hi all, My two cents: I like phrase *commit jungle* and sometimes would like to revert some commits or re-commit things a bit different. I also suppose that it is not that rare when people commit something by mistake or something which has not been tested enough. On the other hand my gut feeling is that (apart from what was said before) changing history is just bad and should be avoided. The commit jungle the result of exactly that - reverting some commits or recommitting with the old commits staying around in many short stumped branches. I think that the git 'rebase' history rewriting could be stated different. Maybe the graph could be altered with fossil cards, the same way commit logs are changed. Then, graph reworking would not imply history rewriting (and thus history loss) as git does. 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] comparison with Git
On Fri, Sep 14, 2012 at 10:48 AM, Lluís Batlle i Rossell vi...@viric.namewrote: On Fri, Sep 14, 2012 at 05:08:53PM +0200, Michal Suchanek wrote: On 14 September 2012 16:57, Jacek Cała jacek.c...@gmail.com wrote: Hi all, My two cents: I like phrase *commit jungle* and sometimes would like to revert some commits or re-commit things a bit different. I also suppose that it is not that rare when people commit something by mistake or something which has not been tested enough. On the other hand my gut feeling is that (apart from what was said before) changing history is just bad and should be avoided. The commit jungle the result of exactly that - reverting some commits or recommitting with the old commits staying around in many short stumped branches. I think that the git 'rebase' history rewriting could be stated different. Maybe the graph could be altered with fossil cards, the same way commit logs are changed. Then, graph reworking would not imply history rewriting (and thus history loss) as git does. Sure, you could have named, alternate timelines and just choose which one to make the default, each timeline forming a namespace for its branches and tags and timelines could inherit from other timelines. That way you could have rabasing without losing history. Bill ___ 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] comparison with Git
2012/9/14 Bill Burdick bill.burd...@gmail.com: Sure, you could have named, alternate timelines and just choose which one to make the default, each timeline forming a namespace for its branches and tags and timelines could inherit from other timelines. That way you could have rabasing without losing history. Hmmm... being pragmatic, who would like to have many timelines in the same project? IMHO that would make things quite complicated or at least unclear. Whereas the 'private' commit tags (which I mentioned above) would make things easier I believe; easier to implement and easier to use. Cheers, Jacek ___ 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] comparison with Git
On Fri, Sep 14, 2012 at 11:00 AM, Jacek Cała jacek.c...@gmail.com wrote: 2012/9/14 Bill Burdick bill.burd...@gmail.com: Sure, you could have named, alternate timelines and just choose which one to make the default, each timeline forming a namespace for its branches and tags and timelines could inherit from other timelines. That way you could have rabasing without losing history. Hmmm... being pragmatic, who would like to have many timelines in the same project? IMHO that would make things quite complicated or at least unclear. Whereas the 'private' commit tags (which I mentioned above) would make things easier I believe; easier to implement and easier to use. Private commit tags sound a little less versatile than Git rebasing. Multiple timelines is only one possibility, though. You could do with just 2, the actual and the public. The public could be a mutable view on the actual, which is immutable. That brings up the question of why there couldn't be more than just 2, of course :). Who would want to have that? I think the Git community answers that. Anyone who wants to have a cleaner presentation of history than what actually happened. Being able to have a clean view without losing the actual history sounds like a good trick, to me, and it would answer the rebasing functionality gap that concerns some people. Bill ___ 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] comparison with Git
2012/9/14 Bill Burdick bill.burd...@gmail.com: Private commit tags sound a little less versatile than Git rebasing. As said above, I don't really know how git rebasing works. Could you shed more light on why it is more versatile than the simple private tags? Cheers, Jacek ___ 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] comparison with Git
Bill Burdick wrote: [...] Who would want to have that? I think the Git community answers that. Anyone who wants to have a cleaner presentation of history than what actually happened. Being able to have a clean view without losing the actual history sounds like a good trick, to me, and it would answer the rebasing functionality gap that concerns some people. Would not the Fossil way to do this be to have two branches, one public and one development, and have periodic merges across from the development branch to the public branch? The public branch would have the 'clean' history, with single checkins containing lots of files representing complete features, but if anyone wants to see the details they can follow the merge into the development branch and see how the work was actually done. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ Parents let children ride bicycles on the street. But parents do not │ allow children to hear vulgar words. Therefore we can deduce that │ cursing is more dangerous than being hit by a car. --- Scott Adams ___ 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] comparison with Git
I'm not an expert on rebasing -- I've only done it a couple times, but as far as I know, rebasing changes the timeline of a branch (potentially radically). It lets you reorder commits, combine them together (squash them), and break them into multiple commits (edit them). I've only done interactive rebasing, which opens an editor with something like this in it (taken from this article, http://git-scm.com/book/en/Git-Tools-Rewriting-History ), listing the commits you want to edit from oldest to newest: pick f7f3f6d changed my name a bit pick 310154e updated README formatting and added blame pick a5f4a0d added cat-file You then change the order of the lines and change whatever commands you want from pick to edit or squash, save the file, and exit the editor, allowing the rebase to continue. Squash combines a commit with the one before it. Edit drops you to command line, where you can create multiple commits and then returns you to the editor again with the new commits you made inserted in the list. Someone could certainly write a tool to do this in Fossil that creates a new branch. On Fri, Sep 14, 2012 at 11:12 AM, David Given d...@cowlark.com wrote: Bill Burdick wrote: [...] Who would want to have that? I think the Git community answers that. Anyone who wants to have a cleaner presentation of history than what actually happened. Being able to have a clean view without losing the actual history sounds like a good trick, to me, and it would answer the rebasing functionality gap that concerns some people. Would not the Fossil way to do this be to have two branches, one public and one development, and have periodic merges across from the development branch to the public branch? The public branch would have the 'clean' history, with single checkins containing lots of files representing complete features, but if anyone wants to see the details they can follow the merge into the development branch and see how the work was actually done. ___ 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] comparison with Git
Rather than comparing Fossil to Git, I compare it to Github, the Git hosting service I'm sure you're all aware of. They've come a long way extending Git to make it easier to use and add the integrated issue tracking/wiki that Fossil has that Git alone doesn't have. Github additionally has some pretty nice looking Windows/Mac GUI desktop apps for managing your local repositories, that automatically set up SSH keys, etc., and make the barrier to entry for Git trivial for those users (let's face it, if you're a linux user, you should already know how to generate SSH keys and do command line stuff, so I guess they didn't feel it was necessary to provide a GUI so far). The key difference between Github and Fossil, in my opinion, is that Github is not open source and is quite expensive to use. I still use Fossil on many personal projects, mostly because I run out of private repositories on Github and am reluctant to increase my plan due to the monthly bill. Github is a bit more shiny as a web application (I would hope so, given the money they've got going in that they can spend on design/feature aspects). Also, there's the fact that you typically provide your own hosting for Fossil (although I know of the Chisel project--looks like that is coming along as well; nice work James.), and the forking social aspect they sell with. One thing I like about Github that I wish Fossil had were email notifications about things like commits and issues created/updated. I know this was discussed years ago, and how it's difficult to set up because you don't know which machine had the changes committed and who has already sent emails out. But I imagine most people interested in this feature use Fossil with a server hosting the main repository, so there should be a flag or something you can send to fossil that would broadcast issue updates/code commits, based on some configuration for an email server to send through. As to the latest emails: The rebase commands come with many warnings about how you shouldn't rewrite history except in your local copy, and people have mixed opinions about that: http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.htmlThe fact of the matter, though, is you can choose whether you want to use that feature of git or not; you're certainly not forced to use it. I somewhat prefer the autosyncing honest way that Fossil uses, but I can see why some people would prefer to have one commit to look through while merging changes in from someone, for example, which is the main use-case for rebase, in my opinion. Anyway, I don't mean to cause a heated discussion. Just throwing out some more noise to this conversation, as one who uses both Fossil and Git on a regular basis. Wes On Fri, Sep 14, 2012 at 12:00 PM, Jacek Cała jacek.c...@gmail.com wrote: 2012/9/14 Bill Burdick bill.burd...@gmail.com: Sure, you could have named, alternate timelines and just choose which one to make the default, each timeline forming a namespace for its branches and tags and timelines could inherit from other timelines. That way you could have rabasing without losing history. Hmmm... being pragmatic, who would like to have many timelines in the same project? IMHO that would make things quite complicated or at least unclear. Whereas the 'private' commit tags (which I mentioned above) would make things easier I believe; easier to implement and easier to use. Cheers, Jacek ___ 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] comparison with Git
So, I think my description above shows why it's more versatile. Rebasing is a tool that reorders, combines, and splits commits. A private tag might be the end result of the editing. Rebasing could be done in fossil, there just isn't a tool to do it (and Git's rebase tools are pretty involved). You could produce a new branch/tag from it, instead of changing one and that would be one way to rebase while preserving history. Alternate timelines could also be a way to group tags/branches and bury the ones that ended up not being important. Bill On Fri, Sep 14, 2012 at 11:11 AM, Jacek Cała jacek.c...@gmail.com wrote: 2012/9/14 Bill Burdick bill.burd...@gmail.com: Private commit tags sound a little less versatile than Git rebasing. As said above, I don't really know how git rebasing works. Could you shed more light on why it is more versatile than the simple private tags? Cheers, Jacek ___ 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] comparison with Git
Wes Freeman freeman@gmail.com wrote: The fact of the matter, though, is you can choose whether you want to use that feature of git or not; you're certainly not forced to use it. Well, you can choose whether or not to use it locally. But once you share the repo, anyone you pull from can use it and force you to live with all the things that caused you to decide not to use it. -- 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] comparison with Git
On 14 September 2012 18:49, Mike Meyer m...@mired.org wrote: Wes Freeman freeman@gmail.com wrote: The fact of the matter, though, is you can choose whether you want to use that feature of git or not; you're certainly not forced to use it. Well, you can choose whether or not to use it locally. But once you share the repo, anyone you pull from can use it and force you to live with all the things that caused you to decide not to use it. What people publish for you to pull depends on them, not the VCS. Even VCS like fossil that does not have native history editing can be coerced. What you pull from them is up to you when you do the pull. 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] comparison with Git
Thanks Bill for the explanation. I see private tags as the end result of 'squash' rather than 'edit'. If you have three commits A-B-C and decide to hide B, you will see A-C. And then diff between C-A will show combined commits B+C against A. Regarding 'edit' and 'reorder', while 'edit' could be useful, I see reordering as asking for troubles. I wonder if anyone uses it with shared repos? ___ 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] comparison with Git
Commit objects in Git are like manifests in Fossil, their id is the hash of their contents, so squash, split, and reorder all end up creating new commit objects with different ids. After a rebase, brach points to the new most-recent commit produced. I'm pretty sure the old commit objects are still around and will only disappear if they aren't part of some other branch and you do a gc. I think if you pull a rebased branch, you can get an error if the commit your branch is no longer in the branch history, at which point you have to decide what to do -- I think you can force the pull, if you want to. If you made changes on the branch, you'd probably have to tag and merge to get it into the new version of the branch. On Fri, Sep 14, 2012 at 12:03 PM, Jacek Cała jacek.c...@gmail.com wrote: Thanks Bill for the explanation. I see private tags as the end result of 'squash' rather than 'edit'. If you have three commits A-B-C and decide to hide B, you will see A-C. And then diff between C-A will show combined commits B+C against A. Regarding 'edit' and 'reorder', while 'edit' could be useful, I see reordering as asking for troubles. I wonder if anyone uses it with shared repos? ___ 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] comparison with Git
Michal Suchanek hramr...@gmail.com wrote: On 14 September 2012 18:49, Mike Meyer m...@mired.org wrote: Wes Freeman freeman@gmail.com wrote: The fact of the matter, though, is you can choose whether you want to use that feature of git or not; you're certainly not forced to use it. Well, you can choose whether or not to use it locally. But once you share the repo, anyone you pull from can use it and force you to live with all the things that caused you to decide not to use it. What you pull from them is up to you when you do the pull. So you end up with two (or more) repos for the same project with different histories? And this is supposed to be better? I think I'm better off choosing software designed to do the job I want done. Which in this case is to preserving history. -- 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] comparison with Git
On 14 September 2012 19:03, Jacek Cała jacek.c...@gmail.com wrote: Thanks Bill for the explanation. I see private tags as the end result of 'squash' rather than 'edit'. If you have three commits A-B-C and decide to hide B, you will see A-C. And then diff between C-A will show combined commits B+C against A. Regarding 'edit' and 'reorder', while 'edit' could be useful, I see reordering as asking for troubles. I wonder if anyone uses it with shared repos? Rebase is often used to bring patches up to date so that they can be efortlessly pulled upstream. You see a repository that has commits A-B-C you clone it and write some changes A-B-C-X-Y-Z but upstream has changed A-B-C-D-E-F so you do a rebase so that your commits can be applied on top of F and send then for review: A-B-C-D-E-F-X'-Y'-Z' If there are no conflicts between your changes and upstream this is fine, otherwise you have to resolve them somehow, and upstream then does not have to. They get nice linear history. This leaves behind a hidden stump with the original X Y and Z commits in git. In fossil the stump would remain and you would have to go out of your way to hide it or not upload it during push. Also if Z is really a fix for a bug in X which is not upstream yet you might want to do an edit - swap Y and Z and squash X and Z so that the upstream reviewer has easier job reviewing fewer patches. A-B-C-D-E-F-X'Z'-Y' Again, you are left with a stump branch. As the stumps thicken you can get quite some jungle. Some filtering to exclude those stumps would help a lot. 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] comparison with Git
Bill Burdick wrote: [...] I think if you pull a rebased branch, you can get an error if the commit your branch is no longer in the branch history, at which point you have to decide what to do -- I think you can force the pull, if you want to. If you made changes on the branch, you'd probably have to tag and merge to get it into the new version of the branch. I can tell you from experience that yes, you do get an error, but no, it is not an informative one. What actually seems to happen is that your upstream apparently conflicts with itself. It took me about a week to sort this out, which I eventually did by nuking the whole repository and starting again. Luckily I hadn't checked anything into it. (What, bitter? Me?) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ Parents let children ride bicycles on the street. But parents do not │ allow children to hear vulgar words. Therefore we can deduce that │ cursing is more dangerous than being hit by a car. --- Scott Adams ___ 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] comparison with Git
2012/9/14 Michal Suchanek hramr...@gmail.com: so you do a rebase so that your commits can be applied on top of F and send then for review: A-B-C-D-E-F-X'-Y'-Z' If there are no conflicts between your changes and upstream this is fine, otherwise you have to resolve them somehow, and upstream then does not have to. They get nice linear history. I don't understand. Without rebase you just merge the other branch (D-E-F) to your cloned and updated repo (X-Y-Z), resolve any conflicts and end up in the same point, ok with one more commit which is the merge of F to Z. This leaves behind a hidden stump with the original X Y and Z commits in git. In fossil the stump would remain and you would have to go out of your way to hide it or not upload it during push. Is a short branch in the timeline such a bad thing really? Also if Z is really a fix for a bug in X which is not upstream yet you might want to do an edit - swap Y and Z and squash X and Z so that the upstream reviewer has easier job reviewing fewer patches. A-B-C-D-E-F-X'Z'-Y' That might be useful. But what if someone was tempted to do this for a fix to a patch that was done 100 commits earlier... Might become tricky I suppose. Cheers, Jacek ___ 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] comparison with Git
On 14 September 2012 20:10, Jacek Cała jacek.c...@gmail.com wrote: 2012/9/14 Michal Suchanek hramr...@gmail.com: so you do a rebase so that your commits can be applied on top of F and send then for review: A-B-C-D-E-F-X'-Y'-Z' If there are no conflicts between your changes and upstream this is fine, otherwise you have to resolve them somehow, and upstream then does not have to. They get nice linear history. I don't understand. Without rebase you just merge the other branch (D-E-F) to your cloned and updated repo (X-Y-Z), resolve any conflicts and end up in the same point, ok with one more commit which is the merge of F to Z. Except with a merge of F-Z you get a single commit which is often huge patch of no value on its own. To understand what it does you have to review the whole branch before the merge possibly with numerous intermediate merges. With rebase you get patches that become part of single, linear history. You can pick only some patches from the start and when there are no interdependencies even just patches from the end or middle, even outside of VCS on top of unpacked release tarball. This leaves behind a hidden stump with the original X Y and Z commits in git. In fossil the stump would remain and you would have to go out of your way to hide it or not upload it during push. Is a short branch in the timeline such a bad thing really? It just makes following the development history more difficult. And when it does not pass the review for the first time it's not going to be just a simple short branch. Especially if you merge, then fix some bugs in stuff before the merge and add fixes as new commits, then merge again, and repeat a few times. Spaghetti. Also if Z is really a fix for a bug in X which is not upstream yet you might want to do an edit - swap Y and Z and squash X and Z so that the upstream reviewer has easier job reviewing fewer patches. A-B-C-D-E-F-X'Z'-Y' That might be useful. But what if someone was tempted to do this for a fix to a patch that was done 100 commits earlier... Might become tricky I suppose. Of course, that's why there is a distinction between 'public' and 'private' branches. You should state when a commit is part of an 'official' history and should no longer be edited. 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] comparison with Git
I'm a faithful Fossil user and I have enjoyed its limitations compared to Git because I consider them features. And pardon my commentary as I typically lurk on the list rather than provide ongoing input to the development. If Git does all of this fancy stuff already, why not just use Git? Why must the beauty and simplicity of Fossil be 'polluted' with this additional baggage? And, if you like some of what Fossil does and some of what Git does, then go and make a bastard stepchild of the two, but please do not advocate putting a bunch of weird stuff into Fossil! *phew* I feel better now that I've said that... :-) -- 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] comparison with Git
Rest assured that even if weird features like rebasing were to pollute Fossil, no one would force you to use them :) On Fri, Sep 14, 2012 at 1:42 PM, Michael L. Barrow mlbar...@barrow.mewrote: I'm a faithful Fossil user and I have enjoyed its limitations compared to Git because I consider them features. And pardon my commentary as I typically lurk on the list rather than provide ongoing input to the development. If Git does all of this fancy stuff already, why not just use Git? Why must the beauty and simplicity of Fossil be 'polluted' with this additional baggage? And, if you like some of what Fossil does and some of what Git does, then go and make a bastard stepchild of the two, but please do not advocate putting a bunch of weird stuff into Fossil! *phew* I feel better now that I've said that... :-) -- michael at barrow dot me +1.408.782.4249 __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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] comparison with Git
On 9/14/12 11:53 AM, Bill Burdick wrote: Rest assured that even if weird features like rebasing were to pollute Fossil, no one would force you to use them :) But the size and complexity of the resulting application which is known for being well-engineered could suffer... -- 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] comparison with Git
On Fri, Sep 14, 2012 at 1:55 PM, Michael L. Barrow mlbar...@barrow.mewrote: On 9/14/12 11:53 AM, Bill Burdick wrote: Rest assured that even if weird features like rebasing were to pollute Fossil, no one would force you to use them :) But the size and complexity of the resulting application which is known for being well-engineered could suffer... True for a generic, unknown feature, maybe, but not for rebasing, I think. Rebasing could be implemented without changing the codebase at all, just using the fossil command in a script. A lot of extensions could be done as external scripts -- both Fossil and Git are very easy to extend, that way. They both have good architectures; Fossil's is SQL and Git's is NoSQL :). Bill ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] comparison with Git
I recall reading somewhere (can't seem to find it at the moment) that fossil is a serverless, zero-administration program. Is that true of git also? Thanks. --Russ P. -- http://RussP.us ___ 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] comparison with Git
On Thu, 13 Sep 2012 00:13:43 -0700 Russ Paielli russ.paie...@gmail.com wrote: I recall reading somewhere (can't seem to find it at the moment) that fossil is a serverless, zero-administration program. Is that true of git also? Thanks. Depends on how you define serverless. Any distributed SCM (Fossil and Git included) is specifically designed to keep all the repository history on a local machine, so if by serverless you mean that an SCM do not need to contact a server to record a commit (or fetch history log or whatever else) then yes, both Fossil and Git are serverless, and so does every other DVCS out there. As to zero-administration, this sounds more like a flame bite rather than a technical consideration: any DVCS system requires certain amount of administration around it. This might possibly refer to the fact Fossil is self-hosting -- you can transfer its binary to a machine, run it and it will serve the specified repository (or a set of them) all by itself as it includes a built-in web-server which is used for both web UI and data pushes/pulls. The real aspect in which Fossil shines, is that it provides a turn-key *integrated* solution consisting of an SCM (obviously), wiki, bug tracker, project documentation editing, and user database with access controls, all accessible/configurable via web UI, and all that is provided by a single 1.2M binary which only depends on libc, zlib and openssl (optionally). This really rocks for certain applications. You could read this classical post by Zed Shaw [1] explaining it all. 1. http://sheddingbikes.com/posts/1276624594.html ___ 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] comparison with Git
On Thu, Sep 13, 2012 at 3:13 AM, Russ Paielli russ.paie...@gmail.comwrote: I recall reading somewhere (can't seem to find it at the moment) that fossil is a serverless, zero-administration program. Is that true of git also? Thanks. We make that claim about the SQLite database engine. See http://www.sqlite.org/about.html Fossil is the DVCS used to manages the SQLite sources, and Fossil is built on top of SQLite. The homepages for Fossil and SQLite are hosted on the same machine. But Fossil and SQLite are not the same thing. --Russ P. -- http://RussP.us ___ 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] comparison with Git
OK, so apparently I misunderstood in thinking that the serverless, zero-administration claim applies to Fossil. Thanks for the clarification. If it were true, and if it distinguished Fossil from Git, I would have used it in my advocacy of Fossil. I am sold on the idea that Fossil is superior to Git on the basis of simplicity alone. Than again, I am currently a minimal Fossil user. Being an aero engineer rather than a developer per se, I'd rather not spend time learning Git. The problem, as I have said before here, is that Git seems to be the de facto standard for open-source software. So not knowing Git essentially shuts you out of most open source. In addition, I feed slightly uncomfortable forcing someone who already knows Git to learn Fossil in order to work on my project. But maybe I shouldn't worry about that. As I said before, it would be great if Fossil could interact with Git at a push/pull level, but as I recall there are technical obstacles to that idea. I am not trying to open up that can of worms again, although maybe I just did. --Russ P. On Thu, Sep 13, 2012 at 4:36 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Sep 13, 2012 at 3:13 AM, Russ Paielli russ.paie...@gmail.comwrote: I recall reading somewhere (can't seem to find it at the moment) that fossil is a serverless, zero-administration program. Is that true of git also? Thanks. We make that claim about the SQLite database engine. See http://www.sqlite.org/about.html Fossil is the DVCS used to manages the SQLite sources, and Fossil is built on top of SQLite. The homepages for Fossil and SQLite are hosted on the same machine. But Fossil and SQLite are not the same thing. --Russ P. -- http://RussP.us ___ 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 -- http://RussP.us ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
