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. 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". So really fossil is not that much simpler than git. It might try to > hide some of the complexity and it may succedd at some times and not > quite at other times and that's it. > > It's true that when you are the sole developer (or the sole developer > with commit access) you can keep (3) (4) (5) the same easily but you > still have to be aware of their existence and avoid actions that would > make them diverge. > > > > > Git does a perfectly awful job of minimizing the amount of state that > > the developer must remember. With the possible exception of > > The idea of the git cli interface design is that you build tools on > top of that interface that may try to hide some of the complexity. > Some GUI tools using git for backend exist but it has not happened for > cli. I guess it comes down to the fact that when there is debug > interface and it's not too different from the user interface in terms > of complexity and you have to learn it at some point anyway you just > keep using the debug interface most of the time. Since there is not > much complexity you can remove and keep the system working in common > everyday situations I guess any attempt at making a simplified > interface proves futile. > > That said, if the git cli interface was meant for humans from the > start it could be probably made more humane in some ways. > Given that the git cli interface was the only interface for humans from the start, I dare say it was meant for humans. As for my use of git (because my employer has been migrating to git from svn for a while now, though we're not 100% migrated yet), I find it maddening. I have used fossil on some projects and wind up committing the "final product" to git when necessary (since git fans seem to find intermediate history objectionable or of little value, it doesn't seem too bad that git doesn't get the same level of history as I have in my repo). -- Scott Robison
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
