On 2 November 2015 at 18:20, Scott Robison <[email protected]> wrote: > On Mon, Nov 2, 2015 at 4:25 AM, Michal Suchanek <[email protected]> wrote: >> >> On 31 October 2015 at 23:33, Richard Hipp <[email protected]> wrote: >> > >> > I'll argue that Git is not beneficial even to people who have mastered >> > its arcane syntax. Here's why: >> > >> > In common usage, Git requires the user to remember the following states: >> > >> > (1) The files being editing in the working directory >> > (2) The files in the staging area >> > (3) The files local repository head >> > (4) The files local copy of the remote repository head >> > (5) The files in the remote repository head >> > >> > Git contains commands for comparing and moving content between all of >> > these different places. That's a lot to keep in mind. Everybody has >> > finite brain capacity. (Some people have more brain capacity than >> > others, but it is still always finite.) The more brain power a >> > developer devotes to keeping track of the VCS, the less is available >> > for working on the application or for solve real problems. To this >> > end, a VCS ought to minimize the amount of state that the developer >> > must remember. >> >> I don't see how you can eliminate anything except (2). You can >> directly commit to repo without any intemediate step but having the >> intermediate step to review your commit before it is set in stone >> would be especially useful for fossil where you do not want to change >> the commit, ever. >> >> Fossil strives to make (3) (4) and (5) the same with autosync but (3) >> will diverge from (5) in absence of commit access and when you are >> offline or commit at the same sync interval somebody advances the >> remote head. You can also avoid having (4) altogether and just report >> error when user tries to advance (3) and it is found that it diverged >> from (5). Resolving or even detecting the conflict without having (4) >> in some form will be challenging, though. > > > As far as there being a staging area, Fossil does have it and it is called > the working directory. Tools like stash and revert (in addition to the > operating system itself) exist to help one manage it. The idea that git's > implementation of a staging area is superior to fossil's working directory > is at least arguable (and I find it laughable), but certainly by any other > name they are conceptually the same thing.
It's different. In git there is Repo - Staging - Workdir and git has tools for adding changes from workdir to staging and then changing current staginig area into new commit. In fossil you can have multiple checkouts but there is afaik no in-fossil tool to jump between them and using an external diff tool does not honor repo settings like excludes. > > Git is built around this idea that history is mutable. Therefore, keeping > track of the local repo head, the local copy of the remote repo head, and > the actual remote repo head imposes a larger cognitive burden than the > fossil model. Ignoring shunning and deliberate manual changes to a > repository, fossil is a system that only grows with time. With git, any of > the three can be modified in ways that make them incompatible with each > other. With fossil, one only needs to worry about "what has been added that > might make a merge difficult". With git, one has to worry about what has > been added, what has been removed, what has been rewritten. The latter two > can make a merge "impossible". Rewriting history in git is your choice. You can use git without rewriting. And really, a merge becoming "impossible" does not really depend on rewriting. If you have conflicting changes you just have conflicting changes. Thanks Michal _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
