16 ms·

Take a look at Fossil too: https://www.fossil-scm.org/ https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people

by henvic 5y ago

Take a look at Fossil too: https://www.fossil-scm.org/ https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people have no idea about how cool the SQLite ecosystem is, and how it's used even on avionics!

pdimitar 5y ago
The lack of ability to squash PRs into single commits is a deal breaker for many, myself included. No, having a commit "fix typo" in the main branch's history is not at all useful and won't ever be. It's noise. In a work setting it's much better to reduce noise.
- emn13 5y ago
  I never understood the point of squashing if you just want the short version, only read the merge commits; if you want the full details to figure out some bug or whatever, then yes, I want those fix typo commits most definitely, because as often as not, those are at fault. Squashing buys you next to nothing, and costs you the ability to dive into the history in greater detail. I suppose if your project is truly huge, it becomes worth it to reduce load on your VCS, but beyond that...
  - pdimitar 5y ago
    Having full history in the feature branch is mandatory -- nobody is disputing that, myself included. All due diligence is done there, not in the main branch. The main branch only needs to have one big commit saying "merging PR #2169". If you need more details you'll go that PR/branch and get your info. The "fix typo" commit being in the main branch buys you nothing. It's only useful in its separate branch.
    - emn13 5y ago
      But that's what a merge commit is - the diff along the merge commit is what the squashed commit would be; the only thing squashing does is "forget" that the second parent exists (terminology for non-git VCS's may be slightly different). Why not merge?
      - pdimitar 5y ago
        Because in big commercial projects several people or teams merge inside the main branch on a regular basis. It's easier to look at a history only including squashed commits each encompassing an entire PR (feature or a bug). It gives you better high-level observability and a good bird's-eye view. And again -- if you need more details you can go and check all separate commits in the PR/branch anyway. And finally, squashed commits are kind of atomic commits. Imagine history of three separate PRs happening at roughly the same time. And now all those commits are interspersed in the history of the main branch. How is that useful or informative? It's chaos. EDIT: my bad, I conflated merging with rebasing. Still, I prefer a single squashed commit for most of the reasons above, plus those of the other two commenters (useful git blame output and buildable history).
        emn13 5y ago
        Oh yeah, rebasing branches as a "merge" policy is definitely tricky like that. (I mean, I'm sure some people do that with and perhaps with good reason, but it makes this kind of stuff clearly worse).
    - skeeter2020 5y ago
      This is fine if its how your team develops but not for everyone. We don't care about full history in branches; maybe it has more detail than main/master but it should still be contextually meaningful. I'd never approve a commit into main with the message "merging PR #xxx" either; it's redundant (merging), has no summary about what it actually does and relies on an external system (your PR/MR process) for details. I do agree that keeping noise out of your main is key, but would go even further than you to keep it clean AND self-contained.
      - pdimitar 5y ago
        Well sure, the title was just an example. It usually is more like this: "Encrypt project's sensitive fields (#1234)" With the number being a PR or an issue # (which does contain a link to the PR). I do care about history in branches though. And many others do. I agree that it varies from team to team.
  - throwaway525142 5y ago
    Squashing for example allows me to have a history where each commit builds. This has been very useful for bisecting for me. I wouldn't call it "next to nothing". The "greater detail" part can cost me a lot of time.
    - emn13 5y ago
      ideally your branch commits would usually build too; but admittedly, I tend to bisect by hand, following the --first-parent. I suppose if the set of commits were truly huge that might be more of an issue. And of course, there are people that have hacked their way to success here: https://stackoverflow.com/a/5652323 https://stackoverflow.com/a/5652323, but that sounds a little fragile.
    - jiofih 5y ago
      Having commits that do not build represents the history more accurately. It could very well be a “fix” to some build error that silently introduces an issue, that context is lost when you squash.
      - throwaway525142 5y ago
        You're not saying anything new as far as I can tell. Your grandparent already said what you said. I only disputed the "this costs next to nothing" part, which you don't seem to comment on.
        jiofih 5y ago
        I was commenting exactly on that. You think having every commit build, at the cost of destroying history, is gaining something. I think representing history correctly is best, and agree that “squashing buys you next to nothing” other than visually pleasant output. Clearer? My favorite approach is rebase + non-ff merge. Best of both worlds.
        jhasse 5y ago
        No. They think having every commit build is gaining something. You think the disadvantage (destroying history) is more important, but you can't say that it "buys you nothing".
  - layoutIfNeeded 5y ago
    I want to be able to tell why a given line of code was introduced. Seeing "Fix indentation" in the output of `git blame` won't help me with that.
    - emn13 5y ago
      git blame --first-parent
    - elliotf 5y ago
      I also want to be able to tell _why_ which is why I dislike working on codebases that squash commmits. Too many times I've done a blame to see why a change was made, and it's a giant (> 10) list of commit messages. Oftentimes, the macro description of what was going on does not help me with the line-level detail. Also, in case it helps you in the future, `blame -wC` is what I use when doing blame; it ignores whitespace changes and tracks changes across files (changes happened before a rename, for example.)
    - gregmac 5y ago
      Neither does squashing though: you still can't tell if that line was introduced or modified. I've come across "fix indentation" or "fix typo" commits where a bug was introduced, like someone accidentally comitted a change (maybe they were debugging something, or just accidentally modified it). For example: I'm tracing a bug where a value isn't staying cached. I find a line of code DefaultCacheAge=10 (which looks way too short) and git blame shows the last change was modifying that value from 86400. What I do next will be very different if the commit message says "fix indentation" vs "added new foobar feature" or "reduced default cache time for (reason)".
  - bastardoperator 5y ago
    Who squashes like this? I rebase all of my PR's not because I want to trash history, but because I want history to be meaningful. If I include all of my "whoops typo fix" and "pay respect to the linter gods" commits, I have made my default branch history much less readable. I would say what you're describing is a break down in CI/CD and code review. How is code that is that broken getting into your default branch in the first place?
    - emn13 5y ago
      I certainly don't, but it's a standard option in git merge (and IIRC github supports it), so I'm pretty sure some teams do. As to rebases to clean up history (and not just the PR itself)... personally, I don't think that's worth it. My experience with history like this is that it's relevant during review, and then around 95% of it is irrelevant - you may not know which 5 % are relevant beforehand, but it's always some small minority. It's worth cleaning up a PR for review, but not for posterity. And when it comes to review, I like commits like "pay respect to the linter gods" and the like, because they're easy to ignore, whereas if you touch code and reformat even slightly in one commit, it's often harder to skip the boring bits; to the point that I'll even intentionally commit poorly formatted code such that the diff is easy to read and then do the reformat later. Removing clear noise (as in code that changes back and forth and for no good reason) is of course nice, but it's easy to overdo; a few typo commits barely impact review-ability (imho), and rebases can and do introduce bugs - you must have encountered semantic merge conflicts before, and those are 10 times as bad with rebases, because they're generally silent (assuming you don't test each commit post-rebase), but leave the code in a really confusing situation, especially when people fix the final commit in the PR, but not the one were the semantic merge conflict was introduced, and laziness certainly encourages that. It also depends on how proficient you are with merge conflicts and git chicanery. If you are; then the history is yours to reshape; but not everybody is, and then I'd rather review an honest history with some cruft, rather than a frankenstein history with odd seams and mismatched stuff in a commit that basically exists because "I kept on prodding git till it worked".
  - skeeter2020 5y ago
    greater detail can ultimately lead to less information if noisy commits crowd out the important ones. IME you want a commit to mean something and that usually leads to tweaking the work/change/commit relationship, which is where squashing helps.
- brundozer 5y ago
  I agree with you that such a commit has nothing to do in the main branch. But it has nothing it do in any branch that is shared with anyone either. Git has enough ways to keep your own history clean at all times to not require a hack like squash PRs to compensate the lack of discipline of a team. With squash PRs you lose so much valuable information that it gets impossible to use commands like bisect or to have a proper context on a blame.
  - pdimitar 5y ago
    I agree that you lose the benefit of a direct bisect but this is usually shrugged off with "you can go to the PR and inspect the commits one by one" which, while not ideal, is deemed a good tradeoff if you want your main branch to only contain big commits each laser-focused on one feature or bug. As I replied to @SQLite above, I am not saying this is the optimal state of affairs -- not at all. But it's what is required everywhere I ever worked for 19.5 years (and similar output was desired when we worked with CVS and Subversion and it was harder to achieve there). But I'll disagree this is lack of discipline. It's not that at all. It's a compromise between programmers, managers/supervisors, CTOs / directors of engineering, and release engineers. They want a bird's-eye view of the project in the main branch.
- SQLite 5y ago
  Fossil does has the ability to squash commits. The difference is that Fossil does not promote the use of commit-squashing. While it can be done, it takes a little work and knowledge of the system. Consider the premature-merge problem in which a feature branch is merged into trunk before it is ready, and subsequent typo fixes need to be added. To do this in Fossil you first move the errant merge onto a new branch (accomplished by adding a tag to the merge check-in) then fix the typo on the original feature branch, then merge again. So in Fossil it is a multi-step process. Fossil does not have a "rebase" command to do all that in one convenient step. Also, Fossil preserves the original errant check-in on the error branch, rather than just "disappearing" the check-in as Git tends to do. The difference here is a question of priorities. What is more important to you, an accurate history or a clean history that tells a story? Fossil prioritizes truth over beauty. If you prefer a retouched or "photoshopped" history over an auditable record of what really happened, Fossil might not be the right choice for you. To put it another way, Fossil can squash commits, but another system might work better for you if commit-squashing is your go-to method of dealing with configuration management problems.
  - pdimitar 5y ago
    I appreciate the different approaches and I'm grateful for the info (and the opinionated take) right from the source. Thank you. In terms of Git and the usual commercial SCM practices, I'm speaking empirically. Everywhere I worked in a team, leaders and managers wanted main branch's history to be a bird's-eye view, to have every commit fully build in CI/CD, and be able to find who introduced a problem (admittedly this requires a little more digging compared to Fossil, though). Squashed commits help when auditing for production breakages, and apparently also helps managers do release management (as well as billing customers sometimes). Do I have all sorts of minor commits in my own projects? Sure! I actually pondered using fossil for them but alas, learning new tools just never gets enough priority due to busy life. I'd love to learn and use it one day. I'm sick of Git. But I don't think your analogy with a photoshopped / retouched picture is fair. Squashing PRs into a single commit is not done for aesthetic reasons or for deliberately disappearing information -- a link to the original PR with its branch and all commits in it remain and can be fully audited after all. No information actually disappeared. I believe a better analogy would be with someone who prefers to have one big photo album that contains smaller albums which in turn contain actual photos of separate life events that are mostly (but not exactly) in chronological order -- as opposed to Fossil's approach which can be likened to a classic big photo album with all semantically unrelated photos put in strict chronological order. I'll reiterate that my observations and opinions are mostly empirical. And let me say that I don't like Git at all. But the practice I described does help in a classic team of programmers and managers. I concede that Git and its quirks represent a local maxima that absolutely can be improved upon, but at least to me the jury is still out on what's the better approach -- and I'm not sure a flat history is it.
- dimitrios1 5y ago
  Consider editing. Yes, a paper goes through revisions, which are holistic, and represent one iteration to the next. But in between those revisions, you can see markups, and editor notes as to why a change was performed. Sometimes those insights are just as useful as the packaged whole.
  - pdimitar 5y ago
    Everybody who ever wrote their own diffing program has considered that and that's not the problem. The problem is how does this approach scale in a repo with 50+ contributors? It doesn't, sadly.
    - dimitrios1 5y ago
      > how does this approach scale in a repo with 50+ contributors? You surely aren't going to have 50 contributors all simultaneously working on the same mainline or feature (or have 50 working together at the same time if ever, if you do, I'd say that's poor project management). The reality is a portion of the developers work on this feature in this part of the code base, a few over here, they'll be on their own branches or lines, and everything will be fine. This scenario where we have 50+ devs all crashing and bumping into each other rarely happens, if ever. I have personally only seen one instance of it happen in kernel development. And even then it was relatively straightforward to sort out. To go further, in a hypothetical scenario where there is one feature and 50+ open source developers are all vying to push their patches in, there is still going to be one reference point to work off of, and reviewers are going to base everything off that. It's a sequential process, not concurrent.
networked 5y ago
Fossil has enough wiki and theming features to power a customized website and to let you edit its contents in the browser. I've joked that Fossil SCM is secretly "Fossil CMS". My personal website, https://dbohdan.com/ https://dbohdan.com/, is powered by Fossil. A year ago I was shopping for a wiki engine, didn't love any I looked at, and realized I could try something I was already familiar with: Fossil. It did take a few hacks to make it work how I wanted. The wiki lacks category and transclusion features and, at least for now [1], can't generate tables of contents. I've invented a simple notation for tags and generate a "tag page" [2] using a Tcl script [3]. The script runs every time I synchronize my local repository with dbohdan.com. The TOC is generated in IE11-compatible JavaScript in the reader's browser [4]. The redirects are in the Caddyfile (not in the repo). Maybe I'll migrate to a more full-featured wiki later [5], but I am enjoying this setup right now. I am happy I gave Fossil a try. Fossil also has a built-in forum engine [6]. I am thinking of migrating a forum running on deprecated software to it. Edit: My favorite music page and sitemap are generated on sync, too. [7] The sitemap uses Fossil's "unversioned content" feature to avoid polluting the timeline (commit history). [8] ----- [1] In the forum thread https://fossil-scm.org/forum/forumpost/b635dc56cb?t=h https://fossil-scm.org/forum/forumpost/b635dc56cb?t=h DRH talks about implementing a server-side TOC. [2] The page lists the tags and what pages are tagged with each. Tags on other pages link to their section of the tag page. https://dbohdan.com/wiki/special:tags https://dbohdan.com/wiki/special:tags. [3] https://dbohdan.com/artifact/8297b54f5d https://dbohdan.com/artifact/8297b54f5d [4] https://dbohdan.com/artifact/d81bb60a0e https://dbohdan.com/artifact/d81bb60a0e [5] PmWiki seems like a nice lightweight option—an order of magnitude less code than its closest competitor DokuWiki, very stable, and has a better page history view. Caveat: it is written in old school PHP. https://pmwiki.org/ https://pmwiki.org/. [6] https://fossil-scm.org/home/doc/trunk/www/forum.wiki https://fossil-scm.org/home/doc/trunk/www/forum.wiki [7] https://dbohdan.com/wiki/music-links https://dbohdan.com/wiki/music-links with https://dbohdan.com/artifact/053d0ff993 https://dbohdan.com/artifact/053d0ff993, https://dbohdan.com/uv/sitemap.xml https://dbohdan.com/uv/sitemap.xml with https://dbohdan.com/artifact/c21444f7c9 https://dbohdan.com/artifact/c21444f7c9. [8] https://fossil-scm.org/home/doc/trunk/www/unvers.wiki https://fossil-scm.org/home/doc/trunk/www/unvers.wiki
- sgbeal 5y ago
systems 5y ago
long long long time ago Fossil destroyed code for Zed Shaw And since that day, not one looked at Fossil the same way, at least not the same way they looked at git https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04665.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... I can't tell for sure how much of impact this had on fossil's adoption, its hard to beat git no matter how good you are, but I think it was a bit hit
- metalliqaz 5y ago
  from the linked thread: > I just cloned your repo. Everything is working fine. Breath, Zed. seems like he panicked and made it worse, then rage-quit
  - jessermeyer 5y ago
    Right. Reading the entire conversation shows the parent messaging is FUD.
    - boygobbo 5y ago
      I've just read it myself and was very impressed by Richard Hipp's calm, courteous and honest demeanour. I would recommend this to anyone as a paragon of how to respond to a difficult situation.
  - JoeQuery 5y ago
    It's been a few years but my one and only interaction with Zed via an email exchange showed me he was quite unstable and prone to outbursts. Never meet your heroes, they say.
    - scruple 5y ago
      I had exactly one interaction with him, too, whereby he shared with me a very long list of companies that he knew of which were hiring at the time, this would've been around 2012 or so. I got quite a few interviews as a result, and quite a few offers, FWIW, though I ended up taking a job with a company that wasn't on this list. I understand both that he is and why he is such a polarizing figure. Just wanted to put my positive anecdote on the pile, since they seem to be a less common when he comes up in online comments.
swiley 5y ago
I don't want forum/web software built into my dvcs. I don't see how this improves over git.

by henvic 5y ago

pdimitar 5y ago

The lack of ability to squash PRs into single commits is a deal breaker for many, myself included. No, having a commit "fix typo" in the main branch's history is not at all useful and won't ever be. It's noise. In a work setting it's much better to reduce noise.

emn13 5y ago
I never understood the point of squashing if you just want the short version, only read the merge commits; if you want the full details to figure out some bug or whatever, then yes, I want those fix typo commits most definitely, because as often as not, those are at fault. Squashing buys you next to nothing, and costs you the ability to dive into the history in greater detail. I suppose if your project is truly huge, it becomes worth it to reduce load on your VCS, but beyond that...
- pdimitar 5y ago
  Having full history in the feature branch is mandatory -- nobody is disputing that, myself included. All due diligence is done there, not in the main branch. The main branch only needs to have one big commit saying "merging PR #2169". If you need more details you'll go that PR/branch and get your info. The "fix typo" commit being in the main branch buys you nothing. It's only useful in its separate branch.
  - emn13 5y ago
    But that's what a merge commit is - the diff along the merge commit is what the squashed commit would be; the only thing squashing does is "forget" that the second parent exists (terminology for non-git VCS's may be slightly different). Why not merge?
    - pdimitar 5y ago
      Because in big commercial projects several people or teams merge inside the main branch on a regular basis. It's easier to look at a history only including squashed commits each encompassing an entire PR (feature or a bug). It gives you better high-level observability and a good bird's-eye view. And again -- if you need more details you can go and check all separate commits in the PR/branch anyway. And finally, squashed commits are kind of atomic commits. Imagine history of three separate PRs happening at roughly the same time. And now all those commits are interspersed in the history of the main branch. How is that useful or informative? It's chaos. EDIT: my bad, I conflated merging with rebasing. Still, I prefer a single squashed commit for most of the reasons above, plus those of the other two commenters (useful git blame output and buildable history).
      - emn13 5y ago
        Oh yeah, rebasing branches as a "merge" policy is definitely tricky like that. (I mean, I'm sure some people do that with and perhaps with good reason, but it makes this kind of stuff clearly worse).
  - skeeter2020 5y ago
    This is fine if its how your team develops but not for everyone. We don't care about full history in branches; maybe it has more detail than main/master but it should still be contextually meaningful. I'd never approve a commit into main with the message "merging PR #xxx" either; it's redundant (merging), has no summary about what it actually does and relies on an external system (your PR/MR process) for details. I do agree that keeping noise out of your main is key, but would go even further than you to keep it clean AND self-contained.
    - pdimitar 5y ago
      Well sure, the title was just an example. It usually is more like this: "Encrypt project's sensitive fields (#1234)" With the number being a PR or an issue # (which does contain a link to the PR). I do care about history in branches though. And many others do. I agree that it varies from team to team.
- throwaway525142 5y ago
  Squashing for example allows me to have a history where each commit builds. This has been very useful for bisecting for me. I wouldn't call it "next to nothing". The "greater detail" part can cost me a lot of time.
  - emn13 5y ago
    ideally your branch commits would usually build too; but admittedly, I tend to bisect by hand, following the --first-parent. I suppose if the set of commits were truly huge that might be more of an issue. And of course, there are people that have hacked their way to success here: https://stackoverflow.com/a/5652323 https://stackoverflow.com/a/5652323, but that sounds a little fragile.
  - jiofih 5y ago
    Having commits that do not build represents the history more accurately. It could very well be a “fix” to some build error that silently introduces an issue, that context is lost when you squash.
    - throwaway525142 5y ago
      You're not saying anything new as far as I can tell. Your grandparent already said what you said. I only disputed the "this costs next to nothing" part, which you don't seem to comment on.
      - jiofih 5y ago
        I was commenting exactly on that. You think having every commit build, at the cost of destroying history, is gaining something. I think representing history correctly is best, and agree that “squashing buys you next to nothing” other than visually pleasant output. Clearer? My favorite approach is rebase + non-ff merge. Best of both worlds.
        jhasse 5y ago
        No. They think having every commit build is gaining something. You think the disadvantage (destroying history) is more important, but you can't say that it "buys you nothing".
- layoutIfNeeded 5y ago
  I want to be able to tell why a given line of code was introduced. Seeing "Fix indentation" in the output of `git blame` won't help me with that.
  - emn13 5y ago
    git blame --first-parent
  - elliotf 5y ago
    I also want to be able to tell _why_ which is why I dislike working on codebases that squash commmits. Too many times I've done a blame to see why a change was made, and it's a giant (> 10) list of commit messages. Oftentimes, the macro description of what was going on does not help me with the line-level detail. Also, in case it helps you in the future, `blame -wC` is what I use when doing blame; it ignores whitespace changes and tracks changes across files (changes happened before a rename, for example.)
  - gregmac 5y ago
    Neither does squashing though: you still can't tell if that line was introduced or modified. I've come across "fix indentation" or "fix typo" commits where a bug was introduced, like someone accidentally comitted a change (maybe they were debugging something, or just accidentally modified it). For example: I'm tracing a bug where a value isn't staying cached. I find a line of code DefaultCacheAge=10 (which looks way too short) and git blame shows the last change was modifying that value from 86400. What I do next will be very different if the commit message says "fix indentation" vs "added new foobar feature" or "reduced default cache time for (reason)".
- bastardoperator 5y ago
  Who squashes like this? I rebase all of my PR's not because I want to trash history, but because I want history to be meaningful. If I include all of my "whoops typo fix" and "pay respect to the linter gods" commits, I have made my default branch history much less readable. I would say what you're describing is a break down in CI/CD and code review. How is code that is that broken getting into your default branch in the first place?
  - emn13 5y ago
    I certainly don't, but it's a standard option in git merge (and IIRC github supports it), so I'm pretty sure some teams do. As to rebases to clean up history (and not just the PR itself)... personally, I don't think that's worth it. My experience with history like this is that it's relevant during review, and then around 95% of it is irrelevant - you may not know which 5 % are relevant beforehand, but it's always some small minority. It's worth cleaning up a PR for review, but not for posterity. And when it comes to review, I like commits like "pay respect to the linter gods" and the like, because they're easy to ignore, whereas if you touch code and reformat even slightly in one commit, it's often harder to skip the boring bits; to the point that I'll even intentionally commit poorly formatted code such that the diff is easy to read and then do the reformat later. Removing clear noise (as in code that changes back and forth and for no good reason) is of course nice, but it's easy to overdo; a few typo commits barely impact review-ability (imho), and rebases can and do introduce bugs - you must have encountered semantic merge conflicts before, and those are 10 times as bad with rebases, because they're generally silent (assuming you don't test each commit post-rebase), but leave the code in a really confusing situation, especially when people fix the final commit in the PR, but not the one were the semantic merge conflict was introduced, and laziness certainly encourages that. It also depends on how proficient you are with merge conflicts and git chicanery. If you are; then the history is yours to reshape; but not everybody is, and then I'd rather review an honest history with some cruft, rather than a frankenstein history with odd seams and mismatched stuff in a commit that basically exists because "I kept on prodding git till it worked".
- skeeter2020 5y ago
  greater detail can ultimately lead to less information if noisy commits crowd out the important ones. IME you want a commit to mean something and that usually leads to tweaking the work/change/commit relationship, which is where squashing helps.
brundozer 5y ago
I agree with you that such a commit has nothing to do in the main branch. But it has nothing it do in any branch that is shared with anyone either. Git has enough ways to keep your own history clean at all times to not require a hack like squash PRs to compensate the lack of discipline of a team. With squash PRs you lose so much valuable information that it gets impossible to use commands like bisect or to have a proper context on a blame.
- pdimitar 5y ago
  I agree that you lose the benefit of a direct bisect but this is usually shrugged off with "you can go to the PR and inspect the commits one by one" which, while not ideal, is deemed a good tradeoff if you want your main branch to only contain big commits each laser-focused on one feature or bug. As I replied to @SQLite above, I am not saying this is the optimal state of affairs -- not at all. But it's what is required everywhere I ever worked for 19.5 years (and similar output was desired when we worked with CVS and Subversion and it was harder to achieve there). But I'll disagree this is lack of discipline. It's not that at all. It's a compromise between programmers, managers/supervisors, CTOs / directors of engineering, and release engineers. They want a bird's-eye view of the project in the main branch.
SQLite 5y ago
Fossil does has the ability to squash commits. The difference is that Fossil does not promote the use of commit-squashing. While it can be done, it takes a little work and knowledge of the system. Consider the premature-merge problem in which a feature branch is merged into trunk before it is ready, and subsequent typo fixes need to be added. To do this in Fossil you first move the errant merge onto a new branch (accomplished by adding a tag to the merge check-in) then fix the typo on the original feature branch, then merge again. So in Fossil it is a multi-step process. Fossil does not have a "rebase" command to do all that in one convenient step. Also, Fossil preserves the original errant check-in on the error branch, rather than just "disappearing" the check-in as Git tends to do. The difference here is a question of priorities. What is more important to you, an accurate history or a clean history that tells a story? Fossil prioritizes truth over beauty. If you prefer a retouched or "photoshopped" history over an auditable record of what really happened, Fossil might not be the right choice for you. To put it another way, Fossil can squash commits, but another system might work better for you if commit-squashing is your go-to method of dealing with configuration management problems.
- pdimitar 5y ago
  I appreciate the different approaches and I'm grateful for the info (and the opinionated take) right from the source. Thank you. In terms of Git and the usual commercial SCM practices, I'm speaking empirically. Everywhere I worked in a team, leaders and managers wanted main branch's history to be a bird's-eye view, to have every commit fully build in CI/CD, and be able to find who introduced a problem (admittedly this requires a little more digging compared to Fossil, though). Squashed commits help when auditing for production breakages, and apparently also helps managers do release management (as well as billing customers sometimes). Do I have all sorts of minor commits in my own projects? Sure! I actually pondered using fossil for them but alas, learning new tools just never gets enough priority due to busy life. I'd love to learn and use it one day. I'm sick of Git. But I don't think your analogy with a photoshopped / retouched picture is fair. Squashing PRs into a single commit is not done for aesthetic reasons or for deliberately disappearing information -- a link to the original PR with its branch and all commits in it remain and can be fully audited after all. No information actually disappeared. I believe a better analogy would be with someone who prefers to have one big photo album that contains smaller albums which in turn contain actual photos of separate life events that are mostly (but not exactly) in chronological order -- as opposed to Fossil's approach which can be likened to a classic big photo album with all semantically unrelated photos put in strict chronological order. I'll reiterate that my observations and opinions are mostly empirical. And let me say that I don't like Git at all. But the practice I described does help in a classic team of programmers and managers. I concede that Git and its quirks represent a local maxima that absolutely can be improved upon, but at least to me the jury is still out on what's the better approach -- and I'm not sure a flat history is it.
dimitrios1 5y ago
Consider editing. Yes, a paper goes through revisions, which are holistic, and represent one iteration to the next. But in between those revisions, you can see markups, and editor notes as to why a change was performed. Sometimes those insights are just as useful as the packaged whole.
- pdimitar 5y ago
  Everybody who ever wrote their own diffing program has considered that and that's not the problem. The problem is how does this approach scale in a repo with 50+ contributors? It doesn't, sadly.
  - dimitrios1 5y ago
    > how does this approach scale in a repo with 50+ contributors? You surely aren't going to have 50 contributors all simultaneously working on the same mainline or feature (or have 50 working together at the same time if ever, if you do, I'd say that's poor project management). The reality is a portion of the developers work on this feature in this part of the code base, a few over here, they'll be on their own branches or lines, and everything will be fine. This scenario where we have 50+ devs all crashing and bumping into each other rarely happens, if ever. I have personally only seen one instance of it happen in kernel development. And even then it was relatively straightforward to sort out. To go further, in a hypothetical scenario where there is one feature and 50+ open source developers are all vying to push their patches in, there is still going to be one reference point to work off of, and reviewers are going to base everything off that. It's a sequential process, not concurrent.

networked 5y ago

Fossil has enough wiki and theming features to power a customized website and to let you edit its contents in the browser. I've joked that Fossil SCM is secretly "Fossil CMS". My personal website, https://dbohdan.com/ https://dbohdan.com/, is powered by Fossil. A year ago I was shopping for a wiki engine, didn't love any I looked at, and realized I could try something I was already familiar with: Fossil. It did take a few hacks to make it work how I wanted. The wiki lacks category and transclusion features and, at least for now [1], can't generate tables of contents. I've invented a simple notation for tags and generate a "tag page" [2] using a Tcl script [3]. The script runs every time I synchronize my local repository with dbohdan.com. The TOC is generated in IE11-compatible JavaScript in the reader's browser [4]. The redirects are in the Caddyfile (not in the repo). Maybe I'll migrate to a more full-featured wiki later [5], but I am enjoying this setup right now. I am happy I gave Fossil a try. Fossil also has a built-in forum engine [6]. I am thinking of migrating a forum running on deprecated software to it. Edit: My favorite music page and sitemap are generated on sync, too. [7] The sitemap uses Fossil's "unversioned content" feature to avoid polluting the timeline (commit history). [8] ----- [1] In the forum thread https://fossil-scm.org/forum/forumpost/b635dc56cb?t=h https://fossil-scm.org/forum/forumpost/b635dc56cb?t=h DRH talks about implementing a server-side TOC. [2] The page lists the tags and what pages are tagged with each. Tags on other pages link to their section of the tag page. https://dbohdan.com/wiki/special:tags https://dbohdan.com/wiki/special:tags. [3] https://dbohdan.com/artifact/8297b54f5d https://dbohdan.com/artifact/8297b54f5d [4] https://dbohdan.com/artifact/d81bb60a0e https://dbohdan.com/artifact/d81bb60a0e [5] PmWiki seems like a nice lightweight option—an order of magnitude less code than its closest competitor DokuWiki, very stable, and has a better page history view. Caveat: it is written in old school PHP. https://pmwiki.org/ https://pmwiki.org/. [6] https://fossil-scm.org/home/doc/trunk/www/forum.wiki https://fossil-scm.org/home/doc/trunk/www/forum.wiki [7] https://dbohdan.com/wiki/music-links https://dbohdan.com/wiki/music-links with https://dbohdan.com/artifact/053d0ff993 https://dbohdan.com/artifact/053d0ff993, https://dbohdan.com/uv/sitemap.xml https://dbohdan.com/uv/sitemap.xml with https://dbohdan.com/artifact/c21444f7c9 https://dbohdan.com/artifact/c21444f7c9. [8] https://fossil-scm.org/home/doc/trunk/www/unvers.wiki https://fossil-scm.org/home/doc/trunk/www/unvers.wiki

sgbeal 5y ago

systems 5y ago

long long long time ago Fossil destroyed code for Zed Shaw And since that day, not one looked at Fossil the same way, at least not the same way they looked at git https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04665.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... I can't tell for sure how much of impact this had on fossil's adoption, its hard to beat git no matter how good you are, but I think it was a bit hit

metalliqaz 5y ago
from the linked thread: > I just cloned your repo. Everything is working fine. Breath, Zed. seems like he panicked and made it worse, then rage-quit
- jessermeyer 5y ago
  Right. Reading the entire conversation shows the parent messaging is FUD.
  - boygobbo 5y ago
    I've just read it myself and was very impressed by Richard Hipp's calm, courteous and honest demeanour. I would recommend this to anyone as a paragon of how to respond to a difficult situation.
- JoeQuery 5y ago
  It's been a few years but my one and only interaction with Zed via an email exchange showed me he was quite unstable and prone to outbursts. Never meet your heroes, they say.
  - scruple 5y ago
    I had exactly one interaction with him, too, whereby he shared with me a very long list of companies that he knew of which were hiring at the time, this would've been around 2012 or so. I got quite a few interviews as a result, and quite a few offers, FWIW, though I ended up taking a job with a company that wasn't on this list. I understand both that he is and why he is such a polarizing figure. Just wanted to put my positive anecdote on the pile, since they seem to be a less common when he comes up in online comments.

swiley 5y ago

I don't want forum/web software built into my dvcs. I don't see how this improves over git.