71–80 of 91 posts
I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text. For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or som…
Earlier quoted context omitted.
Why do you feel that you _have_ to be able to correct history? The past is immutable. Fossil treats it as such. git does not, no matter what configuration you're running - i can always create a fork, modify the history in my fork, and publish that. git has mutable history, period. fossil does not, period. They are different mindsets. i personally don't mind my mistakes staying in the record, and i am suspicious of pe…
> Why do you feel that you _have_ to be able to correct history? We need to distinguish between published history (that was pushed to a central repository) and local history on my laptop. Nobody wants to correct published history. The argument about the audit trail is nice. But compare the value of a single, atomic commit with a long and detailed commit message about what it does (like the ones you see in the linux k…
Sure, "rewriting history" with fossil could be done by anyone with sufficient skill and patience. The lack of such functionality as "first class features" of the software mean that it is unlikely to happen.
Earlier quoted context omitted.
I know plenty of people that simply use SSH or local-only repositories. These people are the minority. Do you know at least 3 million people who use git without github? If not, you're nowhere near to saying that a majority of git users do not use github. And yes, having somewhere to host it is very important. Both Fossil and hg have an httpd built-in. I believe cgit or gitweb are not a simple "git serve" away?
> Do you know at least 3 million people who use git without github? Why must one have never used github while also not using github? I have many private repos I share amongst my machines, but I also publish projects on github when I want them to be public. > Both Fossil and hg have an httpd built-in. That seems horrible. Why do I want these features built in when they can be delegated to other applications (which I c…
Earlier quoted context omitted.
So… not that different from git after all? (rebasing creates new revisions, but while the old ones may not be trivially accessible anymore they're still there until garbage collected)
Rebasing can move whole subtrees around in the repo's history, then publish all those changes back to the repo you cloned from. There is nothing like this in Fossil, on purpose. Fossil's shun operation and private branches are entirely different from rebasing. First, shunning: that just nukes a particular artifact from the local repo, leaving a hole in the history. You can't push a shun operation to another repo, and…
Rebasing does not move subtrees, it copies them.
> Fossil's shun operation and private branches are entirely different from rebasing.
Well considering they apparently genuinely destroy things, quite so.
I'm a long time git, hg and svn user who has been using fossil every day for over a year now and find it to be reliable, quick and easy to use. It is also very hackable and I've customized the "fossil ui" to my liking. However, fossil does lacks some important features that svn, hg and git have: * Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commi…
While that is true, what would revision 2 look like? "This new directory is also empty, but more so?" My point is that an empty directory isn't really "versionable," in the sense that there is something there to be diffed.
I converted a few Subversion repos to Fossil, and the empty directories I'd stored were all easily replaced by a dependency in the build system, so that it was created at the point of need. In that sense, the directory is versioned as part of the Makefile.
In many cases, your existing tooling already takes care of this, as with "bin\Debug" and such in Visual Studio.
> Cannot perform a "fossil diff" for just a directory and its descendants
Yes, that would occasionally be nice.
Fossil does support directory names in checkins, though, so if you're certain the changes are all confined to one subtree, you can just check that change in, then diff what's left.
You can also "stash" a directory, then either diff the stash against the working checkout, or diff what's left, as your workflow requires.
> A "fossil merge" between distributed repos it will give commit attribution to the wrong user
I suspect that's because the full user table isn't included as part of a clone, nor are local user changes pushed back to the repo you cloned from.
The idea of federating identity management gives me the heebie-jeebies. Just ask the PGP folk how well that works.
If repo A clones from B, which clones from C, and you want changes made to A to be properly credited in C, the owners of A need to acquire a login on C, sync themselves to C instead of your B repo, and then check their changes in directly, bypassing B.
Earlier quoted context omitted.
> Ehm, That's not a fair assessment. Git is as much immutable as fossil. I'm not familiar with fossil, but in git if update my HEAD and the REMOTE head isn't a simple fast-forward I get an error. So while the repo's history isn't immutable, each individual commit (and its history) _is_ immutable (modulo sha1 hash collisions). What is the value in having history be static? I find that rebase comes in handy as I'm work…
> What is the value in having history be static? Because you can trust it. Rewritable history is like maintaining your business ledger on a whiteboard. > I find that rebase comes in handy as I'm working locally This idea that local development is a good thing is one of the biggest differences between Git and Fossil. Git was created to serve the needs of the Linux kernel, where the development effort is not only distr…
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.
Earlier quoted context omitted.
> Why do you feel that you _have_ to be able to correct history? We need to distinguish between published history (that was pushed to a central repository) and local history on my laptop. Nobody wants to correct published history. The argument about the audit trail is nice. But compare the value of a single, atomic commit with a long and detailed commit message about what it does (like the ones you see in the linux k…
Nobody wants to correct published history. Yet it still happens. Not that long ago at my office I pulled updates via git to what is to me a read only repo. I never make changes to it. Yet after pulling updates, my repo was in a state claiming I had changes to commit. The whole problem was someone who did rewrite published history. In my case the 'fix' was easy. Delete my clone and reclone. If it had been a project I…
We can debate whether Git's default is sensible or not.
Earlier quoted context omitted.
> Why do you feel that you _have_ to be able to correct history? We need to distinguish between published history (that was pushed to a central repository) and local history on my laptop. Nobody wants to correct published history. The argument about the audit trail is nice. But compare the value of a single, atomic commit with a long and detailed commit message about what it does (like the ones you see in the linux k…
Nobody wants to correct published history. Yet it still happens. Not that long ago at my office I pulled updates via git to what is to me a read only repo. I never make changes to it. Yet after pulling updates, my repo was in a state claiming I had changes to commit. The whole problem was someone who did rewrite published history. In my case the 'fix' was easy. Delete my clone and reclone. If it had been a project I…
Earlier quoted context omitted.
> Having Tickets, the Wiki and technotes in the same place is an interesting idea, Couldn't you just have a `bugs`, and `notes` branch? gugs would be a folder per bug, with each message being a MIME or some similar message format. notes would be a collection of md, rst, textile, &c similar to how github already has a gh-pages branch. It wouldn't need to be part of the scm, but simply be convention.
This sounds horrible. Why would you think this is something people should be subjected to? The polar opposite of user friendly.
2) Even if you just edited files with a text editor, how is that not user friendly? It's about as friendly as it could possibly be.
Earlier quoted context omitted.
> Do you know at least 3 million people who use git without github? Why must one have never used github while also not using github? I have many private repos I share amongst my machines, but I also publish projects on github when I want them to be public. > Both Fossil and hg have an httpd built-in. That seems horrible. Why do I want these features built in when they can be delegated to other applications (which I c…
You can use another httpd if you want to. It's just nice to have one built in if you don't.