6 ms·

I enjoy how well-crafted Fossil seems to be; just like SQLite, which a sibling comment also mentioned. I really want to use Fossil, but it would be way too hard

by kipari 6y ago

I enjoy how well-crafted Fossil seems to be; just like SQLite, which a sibling comment also mentioned. I really want to use Fossil, but it would be way too hard for me to not have the index/staging area of Git. [1] For all the software that claims to be 'opinionated', Fossil really is that. [1]: https://fossil-scm.org/home/doc/trunk/www/gitusers.md https://fossil-scm.org/home/doc/trunk/www/gitusers.md

Arnavion 6y ago
Yes. I use `git add -p` and `git stash -p` all the time and couldn't work without them. Fossil's equivalents appear to let you specify a subset of files to commit / stash, but not individual thunks inside them. [1] [2] Not to mention the lack of `rebase -i` to clean up local commits. [1]: https://www.fossil-scm.org/fossil/help?cmd=commit https://www.fossil-scm.org/fossil/help?cmd=commit [2]: https://www.fossil-scm.org/fossil/help?cmd=stash https://www.fossil-scm.org/fossil/help?cmd=stash
- rstupek 6y ago
  It would seem the authors consider rebase harmful: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
  - mikepurvis 6y ago
    I'm sympathetic to a lot of what they have to say, but this has always been a sticking point for me: > Cherry-picks work better with small check-ins Maybe it's just bad git tooling or me using the tools wrong, but if I need to cherry-pick and there are conflicts, it is always way easier to squash everything down and pick it in one go— if I don't do that, I end up resolving the same conflict over and over as new commits pile in on top of it and meet a conflict-resolved state that they then have a further conflict with.
    - aidenn0 6y ago
      I don't cherry-pick much in git, but I'm guesing rerere doesn't work with it?
      - mikepurvis 6y ago
        I think it probably would for at least some cases, and I'll give it a try definitely.
    - samatman 6y ago
      The author of pijul is of the opinion that cherry-picks only work in accordance with the developer's mental model, if the VCS is based on patches. I've been persuaded by his argument, and I'm really looking forward to the pijul rewrite landing, so I can play around with it again.
    - quesera 6y ago
      > if I don't do that, I end up resolving the same conflict over and over You should check out git rerere. https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere
      - mikepurvis 6y ago
        Interesting, thanks for that! Will try in the future.
  - aidenn0 6y ago
    Contrary to that article, squashing aids bisection rather than hurts it. One simple example: commit 1: things work commit 2: Feature X, regress commit 4: Feature Y, break things by accident commit 5: oops, fix commit #4 ... You land on commit 4 breaking your commit, but if #5 and #4 had been squashed then you would find commit #3 much more easily. With a tiny history like this it's not a big deal, but with a larger one, it becomes an issue.
    - progval 6y ago
      On personal projects (using git), I use squashing only for small bug fixes like the one you mentioned or when the author of a PR made a big mess of commits (usually because they are a git beginner). Best of both worlds.
      - aidenn0 6y ago
        Do you not make a big mess of commits, then selectively squash before submitting a PR?
    - wyoung2 6y ago
      I don't see why you would bisect in this situation in the first place. The problem's fixed now, as of commit 5. But okay, let's take your example as-is: you determine the "good" point is commit 1, and the ...um, other good point is commit 5? Well, that doesn't work. I guess we have to arbitrarily ignore commit 5 and say commit 4 is bad. A bisect will show that. Then in Fossil, if you visit the /info page for commit 4, it will show its child commit 5 as fixing the problem. Try again. Squashing doesn't solve anything here.
      - aidenn0 6y ago
        I'm rebasing because the problem from commit #2 isn't fixed. We have a test that shows the problem from commit #2. However commit #4 breaks things in some way that the test we are running can't run. Squashing the commits together fixes this. If commits #4 and #5 were both on a feature branch before merging, squashing would be done by rebasing in the feature branch. I'm not saying all commits from a feature branch should be squashed to a single commit, but commits like "oops forgot to update header file" or some such are noise. Rewriting history is about improving the signal-to-noise ratio. You may lose some signal (the Fossil argument against it), but if you lose more noise than signal it may be worth it (the git argument for it).
  - Arnavion 6y ago
    (Holy shit I didn't realize how long this had gotten.) I read that page. It's their opinion and I disagree with it. To be clear of where I'm coming from, I've never used fossil, and I've used git regularly for about 10 years. I only use git from the commandline except that I often use `gitk` to read a branch's commit history or inspect diffs, and I use `kdiff3` for interactive merging when there are conflicts. I actively disable git "integrations" in editors and IDEs. --- >1.0 Whether other people struggle with rebase or not does not affect me, because I have no problems using it. (This logic also extends to people who complain the entire git CLI is hard to use.) Now, this might sound like the seasoned C programmer saying "Other people accidentally write UB but I don't, so C is perfectly fine." but there is a difference. UB with C is problematic because it's hard to know it happened, which is why we know the seasoned C programmer might have unknowingly written UB after all. This is not the case with `git rebase` though. Either you do it correctly or you don't, and I can confidently say I do it correctly. >2.1 This is specifically talking about rebases that move commits onto new parents. Rebase does much more than that. For this particular use case, I agree that some projects even when using git prefer to have merge commits instead of rebased commits, and that's fine. But for projects that do want a linear series of commits, it's good to have the choice. Rebased commits also make it easier to revert just a single commit instead of the whole merge (though of course it's not impossible to revert a single commit of a merged branch either). >2.2 This whole section is a non-sequitur because indeed the correct pre-rebase diff would indeed be diff(C2, C5) even in the git case. But if you're planning to rebase the code in order to merge it, you need to rebase the code to know what the diff will be. >3.0 The Windows Vista citation starts off with the (correct) result that lack of communication between engineers of disparate components leads to bugs, but then associates it to mean that these disparate components were being developed in private branches. The cited paper does not talk about branches at all. Indeed, bugs happening because of private branches was not the case then, and is not the case now. The reason those bugs happen is because the engineers of a particular component only work with code of their component. The "egoless" citation is from a book, so I can't tell if the book specifically says private branches have anything to do with ego or not. At any rate, this section is fundamentally confused. Making branches public doesn't mean you can't rebase them. If I work on an OSS github project, I would certainly make my WIP code branch public. That doesn't mean I don't want to rebase it right before I send a PR to clean the cruft up. I think the article author may have read the git advice about not rebasing public branches and thought it meant all non-private branches. It actually means branches other people would want to pull from you and who are not expecting it to be rebased. Single-person development happens in branches only that single person cares about, so whether the branches are private or public makes no difference to that person wanting to be able to rebase them. If a group of people are collaborating and they agree that rebases are going to happen, nothing is wrong with letting them do that. The only problem is with rebasing public branches that people pull from and which those people do not expect to be rebased, like a public repo's `master`. >4.0 So test each commit then. git doesn't makes it impossible to do that or anything. If anything, ensuring tests pass on each intermediate commit makes `bisect`ing easier in the future. Also, only using merges means the only tested commit is the merge commit, so you lose the ability to check which commit in the merged branch caused the problem. See also 7.0 >5.0 `git rebase --ignore-date` will reset the commit date of each rebased commit to the current time. >6.0 It is correct that commit messages are the only way to associate some of the metadata that Fossil lets you manipulate separately. So (2) and (3) do benefit from Fossil's approach. (1) and especially (5) happens rarely enough in my experience that it isn't enough justification. I'm not sure what (4) is referring to by "routine display", but in general the only branches things like `gitk` will show you are the ones you ask for. >7.0 It also throws away non-valuable garbage. When I'm bisecting a bug, or running a `blame` to figure out what commit added a particular line, I don't need to go through half-commits that got reverted afterwards. False starts and incorrect approaches can be documented in the commit message or in the code comments. Also this directly contradicts 4.0 unless we are to assume that only merge commits get tested, and that the user running `blame` does not go deeper than the merge that introduced the line, which has the problem I mentioned in 4.0 >7.1 This section is just a longer reiteration of 7.0, so it has the same rebuttal. >7.2 This has switched to specifically talking about squash rebases, which is not necessarily the only kind of rebase (and is also not the kind of rebase that the diagram in 2.2 was talking about). I also dislike squashed rebases when merging pulls. But if I have to squash two commits in my WIP branch I absolutely want to be able to. >7.3 If the checkins are being rebased and are going to be merged without squashing, then each commit has to stand on its own by definition, so of course they should all have individual justifications. >7.4, 7.5 These are the same as 7.2 and 8.0 below. >8.0 This appears to be saying that fossil's cherry-pick is not just a wrapper around rebase like git's is. So I agree that (1) and (4) are benefits due to Fossil's approach. (2) is exactly the same as 4.0 I don't understand what (3) is trying to say.
JoshTriplett 6y ago
Agreed. I'd love to have integrated bug-tracking, and some of the other features, but Fossil is also trying to drive particular opinions about version control that are incompatible with how many people want to work. It's already hard to move people away from a system that has huge network effects. This makes it much harder.
- beagle3 6y ago
  There are several bug tracking systems that store their data inside the repository (and as a result, branch / merge / push / pull automatically) -- including the venerable "vi bugs.txt" system which works surprisingly well from experience. What fossil brings that those systems don't is indeed the network effect as you pointed out. It's integrated with the web frontend, and is thus used by everyone using fossil and fossil's bug tracking, based on experience with cvstrac, is low ceremony, easy to use and reasonably effective -- even more than "vi bugs.txt" which sets a remarkably low ceremony bar.
  - JoshTriplett 6y ago
    That's exactly what I'd love to have, just without the opinionated differences in things like rebase, staging, branching, and similar.
richie_adler 6y ago
Where did you see opinions in that document? It's a technical description of the functional differences between Fossil and Git, explained with Git terminology.

by kipari 6y ago

Arnavion 6y ago

Yes. I use `git add -p` and `git stash -p` all the time and couldn't work without them. Fossil's equivalents appear to let you specify a subset of files to commit / stash, but not individual thunks inside them. [1] [2] Not to mention the lack of `rebase -i` to clean up local commits. [1]: https://www.fossil-scm.org/fossil/help?cmd=commit https://www.fossil-scm.org/fossil/help?cmd=commit [2]: https://www.fossil-scm.org/fossil/help?cmd=stash https://www.fossil-scm.org/fossil/help?cmd=stash

rstupek 6y ago
It would seem the authors consider rebase harmful: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
- mikepurvis 6y ago
  I'm sympathetic to a lot of what they have to say, but this has always been a sticking point for me: > Cherry-picks work better with small check-ins Maybe it's just bad git tooling or me using the tools wrong, but if I need to cherry-pick and there are conflicts, it is always way easier to squash everything down and pick it in one go— if I don't do that, I end up resolving the same conflict over and over as new commits pile in on top of it and meet a conflict-resolved state that they then have a further conflict with.
  - aidenn0 6y ago
    I don't cherry-pick much in git, but I'm guesing rerere doesn't work with it?
    - mikepurvis 6y ago
      I think it probably would for at least some cases, and I'll give it a try definitely.
  - samatman 6y ago
    The author of pijul is of the opinion that cherry-picks only work in accordance with the developer's mental model, if the VCS is based on patches. I've been persuaded by his argument, and I'm really looking forward to the pijul rewrite landing, so I can play around with it again.
  - quesera 6y ago
    > if I don't do that, I end up resolving the same conflict over and over You should check out git rerere. https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere
    - mikepurvis 6y ago
      Interesting, thanks for that! Will try in the future.
- aidenn0 6y ago
  Contrary to that article, squashing aids bisection rather than hurts it. One simple example: commit 1: things work commit 2: Feature X, regress commit 4: Feature Y, break things by accident commit 5: oops, fix commit #4 ... You land on commit 4 breaking your commit, but if #5 and #4 had been squashed then you would find commit #3 much more easily. With a tiny history like this it's not a big deal, but with a larger one, it becomes an issue.
  - progval 6y ago
    On personal projects (using git), I use squashing only for small bug fixes like the one you mentioned or when the author of a PR made a big mess of commits (usually because they are a git beginner). Best of both worlds.
    - aidenn0 6y ago
      Do you not make a big mess of commits, then selectively squash before submitting a PR?
  - wyoung2 6y ago
    I don't see why you would bisect in this situation in the first place. The problem's fixed now, as of commit 5. But okay, let's take your example as-is: you determine the "good" point is commit 1, and the ...um, other good point is commit 5? Well, that doesn't work. I guess we have to arbitrarily ignore commit 5 and say commit 4 is bad. A bisect will show that. Then in Fossil, if you visit the /info page for commit 4, it will show its child commit 5 as fixing the problem. Try again. Squashing doesn't solve anything here.
    - aidenn0 6y ago
      I'm rebasing because the problem from commit #2 isn't fixed. We have a test that shows the problem from commit #2. However commit #4 breaks things in some way that the test we are running can't run. Squashing the commits together fixes this. If commits #4 and #5 were both on a feature branch before merging, squashing would be done by rebasing in the feature branch. I'm not saying all commits from a feature branch should be squashed to a single commit, but commits like "oops forgot to update header file" or some such are noise. Rewriting history is about improving the signal-to-noise ratio. You may lose some signal (the Fossil argument against it), but if you lose more noise than signal it may be worth it (the git argument for it).
- Arnavion 6y ago
  (Holy shit I didn't realize how long this had gotten.) I read that page. It's their opinion and I disagree with it. To be clear of where I'm coming from, I've never used fossil, and I've used git regularly for about 10 years. I only use git from the commandline except that I often use `gitk` to read a branch's commit history or inspect diffs, and I use `kdiff3` for interactive merging when there are conflicts. I actively disable git "integrations" in editors and IDEs. --- >1.0 Whether other people struggle with rebase or not does not affect me, because I have no problems using it. (This logic also extends to people who complain the entire git CLI is hard to use.) Now, this might sound like the seasoned C programmer saying "Other people accidentally write UB but I don't, so C is perfectly fine." but there is a difference. UB with C is problematic because it's hard to know it happened, which is why we know the seasoned C programmer might have unknowingly written UB after all. This is not the case with `git rebase` though. Either you do it correctly or you don't, and I can confidently say I do it correctly. >2.1 This is specifically talking about rebases that move commits onto new parents. Rebase does much more than that. For this particular use case, I agree that some projects even when using git prefer to have merge commits instead of rebased commits, and that's fine. But for projects that do want a linear series of commits, it's good to have the choice. Rebased commits also make it easier to revert just a single commit instead of the whole merge (though of course it's not impossible to revert a single commit of a merged branch either). >2.2 This whole section is a non-sequitur because indeed the correct pre-rebase diff would indeed be diff(C2, C5) even in the git case. But if you're planning to rebase the code in order to merge it, you need to rebase the code to know what the diff will be. >3.0 The Windows Vista citation starts off with the (correct) result that lack of communication between engineers of disparate components leads to bugs, but then associates it to mean that these disparate components were being developed in private branches. The cited paper does not talk about branches at all. Indeed, bugs happening because of private branches was not the case then, and is not the case now. The reason those bugs happen is because the engineers of a particular component only work with code of their component. The "egoless" citation is from a book, so I can't tell if the book specifically says private branches have anything to do with ego or not. At any rate, this section is fundamentally confused. Making branches public doesn't mean you can't rebase them. If I work on an OSS github project, I would certainly make my WIP code branch public. That doesn't mean I don't want to rebase it right before I send a PR to clean the cruft up. I think the article author may have read the git advice about not rebasing public branches and thought it meant all non-private branches. It actually means branches other people would want to pull from you and who are not expecting it to be rebased. Single-person development happens in branches only that single person cares about, so whether the branches are private or public makes no difference to that person wanting to be able to rebase them. If a group of people are collaborating and they agree that rebases are going to happen, nothing is wrong with letting them do that. The only problem is with rebasing public branches that people pull from and which those people do not expect to be rebased, like a public repo's `master`. >4.0 So test each commit then. git doesn't makes it impossible to do that or anything. If anything, ensuring tests pass on each intermediate commit makes `bisect`ing easier in the future. Also, only using merges means the only tested commit is the merge commit, so you lose the ability to check which commit in the merged branch caused the problem. See also 7.0 >5.0 `git rebase --ignore-date` will reset the commit date of each rebased commit to the current time. >6.0 It is correct that commit messages are the only way to associate some of the metadata that Fossil lets you manipulate separately. So (2) and (3) do benefit from Fossil's approach. (1) and especially (5) happens rarely enough in my experience that it isn't enough justification. I'm not sure what (4) is referring to by "routine display", but in general the only branches things like `gitk` will show you are the ones you ask for. >7.0 It also throws away non-valuable garbage. When I'm bisecting a bug, or running a `blame` to figure out what commit added a particular line, I don't need to go through half-commits that got reverted afterwards. False starts and incorrect approaches can be documented in the commit message or in the code comments. Also this directly contradicts 4.0 unless we are to assume that only merge commits get tested, and that the user running `blame` does not go deeper than the merge that introduced the line, which has the problem I mentioned in 4.0 >7.1 This section is just a longer reiteration of 7.0, so it has the same rebuttal. >7.2 This has switched to specifically talking about squash rebases, which is not necessarily the only kind of rebase (and is also not the kind of rebase that the diagram in 2.2 was talking about). I also dislike squashed rebases when merging pulls. But if I have to squash two commits in my WIP branch I absolutely want to be able to. >7.3 If the checkins are being rebased and are going to be merged without squashing, then each commit has to stand on its own by definition, so of course they should all have individual justifications. >7.4, 7.5 These are the same as 7.2 and 8.0 below. >8.0 This appears to be saying that fossil's cherry-pick is not just a wrapper around rebase like git's is. So I agree that (1) and (4) are benefits due to Fossil's approach. (2) is exactly the same as 4.0 I don't understand what (3) is trying to say.

JoshTriplett 6y ago

Agreed. I'd love to have integrated bug-tracking, and some of the other features, but Fossil is also trying to drive particular opinions about version control that are incompatible with how many people want to work. It's already hard to move people away from a system that has huge network effects. This makes it much harder.

beagle3 6y ago
There are several bug tracking systems that store their data inside the repository (and as a result, branch / merge / push / pull automatically) -- including the venerable "vi bugs.txt" system which works surprisingly well from experience. What fossil brings that those systems don't is indeed the network effect as you pointed out. It's integrated with the web frontend, and is thus used by everyone using fossil and fossil's bug tracking, based on experience with cvstrac, is low ceremony, easy to use and reasonably effective -- even more than "vi bugs.txt" which sets a remarkably low ceremony bar.
- JoshTriplett 6y ago
  That's exactly what I'd love to have, just without the opinionated differences in things like rebase, staging, branching, and similar.

richie_adler 6y ago

Where did you see opinions in that document? It's a technical description of the functional differences between Fossil and Git, explained with Git terminology.