On May 11, 2016, at 4:24 PM, Marko Käning <sec001+fos...@posteo.net> wrote: > > Is this deliberately missing functionality following fossil's mission to keep > all history?
I suspect it’s more likely the case that fossil private branches are a subset of the functionality of regular branches, and we’re philosophically opposed to adding such a feature for the regular checkin mechanism. Keep in mind also that Fossil does 1-step commits by default. That is, fossil autosync is on, so there is no separate push step. We don’t talk about staging areas and such in Fossil. The normal pattern is that all work is public, by default. This avoids the “guy in the room” problem first documented by Gerald Weinberg in his influential 1971 book “The Psychology of Computer Programming,” where a perfectionist developer spends weeks secretly working on changes without talking to anyone about what they’re doing. Then, boom, a big bolus of changes lands all at once, potentially screwing up other developers’ work. The Fossil alternative is to make risky changes on a public branch so your coworkers/collaborators can see what you’re doing, and thus potentially save you both a lot of time and hassle if they see you committing questionable code. Or at the least, it lets those same people see what you’re doing, agree that it’s a good direction, and make sure they’re ready when your code is finally merged back in. This plays into another key bit of advice in Weinberg’s book: practice egoless programming. You are not your code. Yes, working on public branches means you might end up being foolish in public. But, it also means your foolishness can be corrected quickly, before it causes a lot of damage. As long as your coworkers and bosses understand that you might not be perfect, and that everyone makes mistakes, and that everyone can and should learn from them, this is not a problem. The wish to commit only perfected features publicly is usually either a sign of egotism, arrogance, or a culture that punishes people for being imperfect. Regardless of the actual cause, it’s a social problem, not a technical problem. Seeking technical workarounds for social problems merely avoids solving the actual problem. That only good reason for private branches is when you have a public repo and you need to develop some code that simply cannot be public, such as for some legal reason. For example, one of the SQLite developers might be contracted to write a feature or fix for one specific company, and that company doesn’t want the change to go back into SQLite. This is not a common case, so I don’t see that a lot of developer time should go into supporting it. Private branches should be unpleasant to use to discourage that use. :) > No plans to implement a (perhaps restricted) squash command which would only > work on private branches? I think the trick would be to write such code that works on all branches, but then somehow prevent it from being used on anything but private branches. Sounds like a disaster waiting to happen. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
