4 ms·

> Because you can trust it. Rewritable history is like maintaining your business ledger on a whiteboard. You can trust a git commit to never change. > You wil

> Because you can trust it. Rewritable history is like maintaining your business ledger on a whiteboard. You can trust a git commit to never change. > You will make mistakes, but Git encourages you to hide them in the stash, in private branches, in changed checkin comments (git commit --amend), and in history rewrites. In its default working mode, That is not the purpose of any of those things, nor is the purpose to "hide" anything. The purpose is to make the history more understandable and give you the ability to compartmentalize changes. While you shouldn't be working on multiple things, I and most other people I met, end up doing so. Being able to split those into commits all about the same thing is handy. > 2. You are not your code. Private branches are a symptom of the sort of perfectionism that violates this commandment. It's not protectionist or perfectionist to keep non-working code out of the main branch. If I'm rewriting something, why should everyone else have a non-working version of it for the duration of the rewrite? > Don't rewrite other people's code without consultation You can't work on a project with other people without using their code, and often you _can't_ consult them. Sure, don't autoformat, &c. I don't see how private branches encourage of facilitate this. People will do what people will do. I've seen people do this in subversion, so I don't see your point. > You don't want to find out a week later when you and your colleague both try to check in week-old private branches, and find that you'll need another day or two of work to fix up the differences. I'm not sure what you're talking about as I've never had such a terrible merge in git (though I have in subversion). > Don't be "the guy in the room." But Git wants you to be that guy. Before you can check a change in with Fossil, it first checks if there are any changes in the repo you cloned from, and makes you either say "fossil up" to pull them into your local repo, or check in on a branch. This encourages you to either test your changes against the tip of trunk before checkin in, or at least publish your changes as a branch so people can see you go haring off in a different direction, and maybe correct your trajectory. You can't push a non fast-forward by default. (You can force, but that can be disabled and is heavily discouraged.) I'm not seeing why your model is inherently any better than make sure tests pass after a merge. Again, it's up to the dev, not the scm. > Not all merge conflicts can be detected by the VCS's merge algorithm. Just because your changes merge cleanly into the central code repo doesn't mean you haven't broken the build, or the tests, or... Fossil encourages you to test your change against the tip of the branch you're working on before checking in. Fossil does not, your build and project environments do. > Git amounts to a social regression with respect to Egoless Programming. I have no idea what you even mean. Git is about giving you the tools to make code changes that make sense, without the need to obtain someone's blessing over your code. All other decisions are yours and yours alone. I can not test in SVN, Fossil, CVS, Perforce, &c. I can edit other people's code as well. Nothing is stopping me but convention and what I decide to do.

wyoung2 11y ago
> While you shouldn't be working on multiple things, I and most other people I met, end up doing so Fossil solves that with branches. Merging a branch into the trunk is equivalent to what Git calls pushing. The difference is that everyone can see your branch, unless you use a private branch, which is more like Git. I've argued the advantages of working on a public branch already, though, so I won't repeat that here. That reminds me of another big difference between Fossil and Git. With Git, the checkout tree and the local repo clone are tied up in a single directory tree. The normal way to switch branches is to check all of your local changes in, then switch the current working directory over to the other branch. While you can do that in Fossil, too, because the repository is a separate file, when working with long-lived branches, it is easier to have separate checkout trees, one for each such branch. The advantage is that switching branches doesn't change all the timestamps for changed files, invalidating build artifacts and such. To get the same effect with Git, you have to clone the whole repo for each long-lived branch, which complicates things greatly, and wastes a bunch of disk space. > It's not protectionist or perfectionist to keep non-working code out of the main branch So check it in on a feature branch or a private branch. Once the new feature in the branch functions as intended, merge it into the trunk. > why should everyone else have a non-working version of it for the duration of the rewrite? If it's a public branch, their Fossil pulls will indeed give them a copy of your branch, but they will only be able to see your checkin comments in the Timeline view, by default. That tells your team members what you're working on, which, as I've already argued, is a good thing. If they have concerns about your direction, they can switch to your branch (a la Git) or check it out into a separate working tree. Or, they can just ignore it, and let you get about your business. > often you _can't_ consult them I already stated it above: if you're working on a project where you're not really collaborating with people, and where haring off in your own direction is a normal thing, then Git may well be the correct tool for you. Fossil is for coherent projects, where people are expected to work together. The SQLite project, which Fossil was created for, is an example of this: to join the project, you have to first impress someone enough to get a commit bit, then you sign the contributor agreement. You are expected to participate on the developer mailing list once accepted. Fossil is also good for traditional corporate development, where those with commit bits are your coworkers. > I don't see how private branches encourage of facilitate [rewriting other people's code] Git's normal working model is that your checkins are local first, then only optionally pushed back to the repo you cloned from. I'd bet a whole lot of the forks on GitHub will no longer integrate back into the parent project. You can see this in the language they use: forking. This is not necessarily a bad thing. If you need federated development, Git's your tool. But if instead you're after collaborators, contributors, and coworkers, you don't want forking the repo to be the normal first step. > I'm not seeing why your model is inherently any better than make sure tests pass after a merge. The "guy in the room" spends days or weeks working on code without showing anyone what he's up to. Then there is a big-bang merge event, which may or may not succeed, and may wreck his coworkers plans. If you ignore private branches in Fossil, you end up either working on the trunk, where your coworkers will immediately see your changes, or working on a public branch, where they're likely to at least see your checkin comments, and can look at your changes if they become concerned about your direction. If you're working on a public branch, you still have the merge event, but your coworkers can't really say they're surprised when it happens, since they've been seeing your work as it progresses. On the Fossil mailing list, you frequently see one of the core developers claiming to have finished a feature, asking for comment on their feature branch before merging it. The "guy in the room" doesn't ask for comment; he just drops his magnum opus into the trunk and says "deal with it." > Fossil does not, your build and project environments do. You've misunderstood my point. Because Fossil defaults to "autosync on", you can't check in a change on a branch that has upstream changes. Fossil simply won't allow it. (There's a "force" option, but it creates a special kind of branch called a fork, which has to be resolved at some point.) This means that if someone else changes the branch in a way that breaks the tests or whatever, Fossil strongly encourages you to pull those changes into your checkout where you can deal with it. Git, by contrast, lets individual developers do all their checkins on a private branch, then push the whole thing to the repo they cloned from. GitHub embodies this in the pull request. There is no equivalent in Fossil, because Fossil isn't intended for federated development; it's for collaborative development. > Nothing is stopping me but convention and what I decide to do. This is why we have social mores and community standards of behavior. It is a good thing if the tools we use support those desirable behaviors.

wyoung2 11y ago

> While you shouldn't be working on multiple things, I and most other people I met, end up doing so Fossil solves that with branches. Merging a branch into the trunk is equivalent to what Git calls pushing. The difference is that everyone can see your branch, unless you use a private branch, which is more like Git. I've argued the advantages of working on a public branch already, though, so I won't repeat that here. That reminds me of another big difference between Fossil and Git. With Git, the checkout tree and the local repo clone are tied up in a single directory tree. The normal way to switch branches is to check all of your local changes in, then switch the current working directory over to the other branch. While you can do that in Fossil, too, because the repository is a separate file, when working with long-lived branches, it is easier to have separate checkout trees, one for each such branch. The advantage is that switching branches doesn't change all the timestamps for changed files, invalidating build artifacts and such. To get the same effect with Git, you have to clone the whole repo for each long-lived branch, which complicates things greatly, and wastes a bunch of disk space. > It's not protectionist or perfectionist to keep non-working code out of the main branch So check it in on a feature branch or a private branch. Once the new feature in the branch functions as intended, merge it into the trunk. > why should everyone else have a non-working version of it for the duration of the rewrite? If it's a public branch, their Fossil pulls will indeed give them a copy of your branch, but they will only be able to see your checkin comments in the Timeline view, by default. That tells your team members what you're working on, which, as I've already argued, is a good thing. If they have concerns about your direction, they can switch to your branch (a la Git) or check it out into a separate working tree. Or, they can just ignore it, and let you get about your business. > often you _can't_ consult them I already stated it above: if you're working on a project where you're not really collaborating with people, and where haring off in your own direction is a normal thing, then Git may well be the correct tool for you. Fossil is for coherent projects, where people are expected to work together. The SQLite project, which Fossil was created for, is an example of this: to join the project, you have to first impress someone enough to get a commit bit, then you sign the contributor agreement. You are expected to participate on the developer mailing list once accepted. Fossil is also good for traditional corporate development, where those with commit bits are your coworkers. > I don't see how private branches encourage of facilitate [rewriting other people's code] Git's normal working model is that your checkins are local first, then only optionally pushed back to the repo you cloned from. I'd bet a whole lot of the forks on GitHub will no longer integrate back into the parent project. You can see this in the language they use: forking. This is not necessarily a bad thing. If you need federated development, Git's your tool. But if instead you're after collaborators, contributors, and coworkers, you don't want forking the repo to be the normal first step. > I'm not seeing why your model is inherently any better than make sure tests pass after a merge. The "guy in the room" spends days or weeks working on code without showing anyone what he's up to. Then there is a big-bang merge event, which may or may not succeed, and may wreck his coworkers plans. If you ignore private branches in Fossil, you end up either working on the trunk, where your coworkers will immediately see your changes, or working on a public branch, where they're likely to at least see your checkin comments, and can look at your changes if they become concerned about your direction. If you're working on a public branch, you still have the merge event, but your coworkers can't really say they're surprised when it happens, since they've been seeing your work as it progresses. On the Fossil mailing list, you frequently see one of the core developers claiming to have finished a feature, asking for comment on their feature branch before merging it. The "guy in the room" doesn't ask for comment; he just drops his magnum opus into the trunk and says "deal with it." > Fossil does not, your build and project environments do. You've misunderstood my point. Because Fossil defaults to "autosync on", you can't check in a change on a branch that has upstream changes. Fossil simply won't allow it. (There's a "force" option, but it creates a special kind of branch called a fork, which has to be resolved at some point.) This means that if someone else changes the branch in a way that breaks the tests or whatever, Fossil strongly encourages you to pull those changes into your checkout where you can deal with it. Git, by contrast, lets individual developers do all their checkins on a private branch, then push the whole thing to the repo they cloned from. GitHub embodies this in the pull request. There is no equivalent in Fossil, because Fossil isn't intended for federated development; it's for collaborative development. > Nothing is stopping me but convention and what I decide to do. This is why we have social mores and community standards of behavior. It is a good thing if the tools we use support those desirable behaviors.