3 ms·

I like a lot about Fossil and moved many projects into it for a while. What I eventually couldn't tolerate was the lack of rebase (and history rewriting in gene

by LVB 10y ago

I like a lot about Fossil and moved many projects into it for a while. What I eventually couldn't tolerate was the lack of rebase (and history rewriting in general). There are extensive debates going back years on the Fossil mailing list about the topic, but ultimately the authors were pretty firm that rebase/rewriting history is bad and they didn't want to support it. My local workflow uses commit rewriting a lot in order to keep a useful history. I commit like crazy and then squash/reorder/rebase to make a nice logical history (http://gitup.co http://gitup.co is awesome for this on OSX, BTW). I couldn't do this, at least at the time, with Fossil, and ended up with piles of not-very-useful commits.

cm3 10y ago
Yeah, git doesn't restrict you in that regard and supports both workflows, which may differ from project to project. Mercurial has a nice improved version of this, where it's safe to rewrite locally but you're not allowed to rewrite public history. I think that's a smart compromise, although if the project you're working on has the concept of patch queues, like the linux kernel and others, then mutable history to maintain patch queues is a feature, which in fact had been supported by a few extensions before the new mercurial rebase implementation landed.
- petre 10y ago
  Fossil also has private branches.
  - cm3 10y ago
    Can you rewrite history in those?
    - petre 10y ago
      No, you cannot rewrite history at all in fossil. But you can commit repeatedly to the private branch and when finished merge all the changes into a public branch. It will look like a single commit. https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki
midnightmonster 10y ago
I think the fossil way would be to do your work on a branch and then merge the branch. Merges are squashed automatically, and it's easy to retroactively designate a commit as the beginning of a new branch in case you didn't realize where you were going when you started.
- wyoung2 10y ago
  Yes, exactly this. Not only does working on a branch sequester each developer's individual insanities until merge time, it lets other team members keep an eye on that branch so there aren't big surprises when merge time comes around. We want both aspects, not just one or the other. Back in the early days of computing, a programming team was likely to share a single expensive computer. Then we had the PC revolution, so each developer could have his own computer, but we kept those devs in cube farms or similar shared working spaces, and they had a LAN to coordinate their work. Then the Internet happened, and we started doing distributed development, so we invented Subversion and mailing lists and suchlike to give team members a way to coordinate their efforts. Then we got DVCSes, which have their uses, but they cause a new problem, which is that they let developers fork the project and go off on a tangent, completely unmonitored. When they pop up weeks or months later with a new feature, that feature may not even merge cleanly, or if it does, it may not align with the core developers' vision of where the project is going. So, the fork is never healed, and you end up with a choice of forks, no better than old-style project forks, where the dissenters just copied the project repo. This problem was solved in the Git world by Github, which effectively turns forks into a special kind of branch, in that you can trace forks from parent repos to children, and merge child forks back in just as easily as internal branches. Fossil solves it differently by strongly encouraging a central-and-clones model: it helps maintain team cohesion in a distributed development environment. Fossil actively fights against users going off on a tangent. This is a good thing. You can force Fossil to work like stock Git, but its default configuration fights against that, on purpose.
hvidgaard 10y ago
I used to belong to the no-rewrite history camp. But after maintaining a repository for a team of developers that is not as punctual with commits and history as myself, it has made me value rebase quite a bit. I'm not overly concerned with authenticity of the history until it's on the live branch, and I prefer a clean history above all.

by LVB 10y ago

cm3 10y ago

Yeah, git doesn't restrict you in that regard and supports both workflows, which may differ from project to project. Mercurial has a nice improved version of this, where it's safe to rewrite locally but you're not allowed to rewrite public history. I think that's a smart compromise, although if the project you're working on has the concept of patch queues, like the linux kernel and others, then mutable history to maintain patch queues is a feature, which in fact had been supported by a few extensions before the new mercurial rebase implementation landed.

petre 10y ago
Fossil also has private branches.
- cm3 10y ago
  Can you rewrite history in those?
  - petre 10y ago
    No, you cannot rewrite history at all in fossil. But you can commit repeatedly to the private branch and when finished merge all the changes into a public branch. It will look like a single commit. https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki

midnightmonster 10y ago

I think the fossil way would be to do your work on a branch and then merge the branch. Merges are squashed automatically, and it's easy to retroactively designate a commit as the beginning of a new branch in case you didn't realize where you were going when you started.

wyoung2 10y ago
Yes, exactly this. Not only does working on a branch sequester each developer's individual insanities until merge time, it lets other team members keep an eye on that branch so there aren't big surprises when merge time comes around. We want both aspects, not just one or the other. Back in the early days of computing, a programming team was likely to share a single expensive computer. Then we had the PC revolution, so each developer could have his own computer, but we kept those devs in cube farms or similar shared working spaces, and they had a LAN to coordinate their work. Then the Internet happened, and we started doing distributed development, so we invented Subversion and mailing lists and suchlike to give team members a way to coordinate their efforts. Then we got DVCSes, which have their uses, but they cause a new problem, which is that they let developers fork the project and go off on a tangent, completely unmonitored. When they pop up weeks or months later with a new feature, that feature may not even merge cleanly, or if it does, it may not align with the core developers' vision of where the project is going. So, the fork is never healed, and you end up with a choice of forks, no better than old-style project forks, where the dissenters just copied the project repo. This problem was solved in the Git world by Github, which effectively turns forks into a special kind of branch, in that you can trace forks from parent repos to children, and merge child forks back in just as easily as internal branches. Fossil solves it differently by strongly encouraging a central-and-clones model: it helps maintain team cohesion in a distributed development environment. Fossil actively fights against users going off on a tangent. This is a good thing. You can force Fossil to work like stock Git, but its default configuration fights against that, on purpose.

hvidgaard 10y ago

I used to belong to the no-rewrite history camp. But after maintaining a repository for a team of developers that is not as punctual with commits and history as myself, it has made me value rebase quite a bit. I'm not overly concerned with authenticity of the history until it's on the live branch, and I prefer a clean history above all.