10 ms·

The incorrect merge is preserved because that is what actually happened. The incorrect merge was published. People saw it (and commented on it in the SQLite F

by SQLite 5y ago

The incorrect merge is preserved because that is what actually happened. The incorrect merge was published. People saw it (and commented on it in the SQLite Forum). If I "disappear" the merge, that would be airbrushing history. The correct solution is to fix the problem, while maintaining an immutable audit trail, not to delete the problem. When I was in high school, I was taught that if I worked as a bookkeeper and I make a mistake, I should never erase the mistake. Instead, draw a line through the mistake, notate what is wrong, and enter a correction. To erase an entry in the financial ledger of a company is fraud. It is a felony. Making a correction is fine. But do not erase. Always preserve an audit trail. I believe that VCSes should be treated similarly. While you are assembling a change, you can make as many erasures and corrections as you like. But once you commit the transaction - once you check-in the change - it then becomes part of the permanent record. To alter that transaction after the fact is akin to felony fraud. Sure, mistakes happen. By all means, correct the mistakes. But the original mistake and the correction should all be part of the audit history. If you want to say that commits to your private branches are not part of the permanent record, and that you should therefore be permitted to edit those private branches, then I think you have a stronger case. That does not come up as much in Fossil. Fossil does support private branches, but they are seldom used. The usual case in Fossil is that all check-ins auto-sync up to the parent repo. Shunning is not quite the same. Shunning is a mechanism for removing illegal are illegitimate content. Shunning is sometimes required to comply with legal mandates. But it is not a part of day-to-day practice. Shunning is an exception - and escape valve - undertaken only in an emergency.

thayne 5y ago
> If you want to say that commits to your private branches are not part of the permanent record, and that you should therefore be permitted to edit those private branches, then I think you have a stronger case. That does not come up as much in Fossil. Fossil does support private branches, but they are seldom used. The usual case in Fossil is that all check-ins auto-sync up to the parent repo. This is probably one of my biggest problems with fossil. It is very opinionated about the workflow you use. My typical workflow involves making many commits on a private branch while working on something, many of which won't be able to build or pass tests, and then clean everything up before pushing to a publicly visible branch. This allows me to easily roll back if an approach ends up not working out, or cherry-pick smaller changes to other branches if a change ends up being needed in multiple feature branches in progress at once, etc. With git that sort of workflow is trivial, with fossil, it might be possible, but it doesn't fit with fossil's blessed workflow. Git on the otherhand is pretty flexible, and can be used for a lot of different workflows, and doesn't push you towards a specific one.
kazinator 5y ago
An automatic merge is just some algorithm's often poor idea of how some parallel changes should be integrated. This has to be verified by a software engineer and put through QA, and adjusted as necessary so that it works to the best of everyone's knowledge. Then you publish the result as the result of the merge. If you commits the result of a merge before doing anything with it to fix it up, that implies that you will sometimes be committing non-buildable code which still contains conflict markers. That's not even allowed under a continuous integration policy that every build has to build (and pass unit tests and whatnot).
TeeMassive 5y ago
As I was reading your comment I caught myself thinking this was a post defending git but then I saw you username. All of what you mention are what git allows to do and also how git is used 99.9% of the time. I can't help but notice your lack of experience with Git, and I say that very respectfully. Most organizations' repositories will have one or more protected branches (e.g. master). What is published there remain. Even mistakes. When the history on those branches are erased it is for very good reasons only. Usually it involves the size of the repository getting too big, illegal / private content and paths only differing by lower and upper case messing with Git on Windows. Even in those very rare cases the history of the vast majority of the files remain. And this is also something all CVS has to face so this is not specific to Git itself. Dev branches are pushed, overwritten and erased. I don't see how that's a problem. In the end having small intelligible commits that reads like a dish recipe accelerates code reviews and corrections and I haven't seen any other VCSes doing that as efficiently as Git.
- kazinator 5y ago
  > Most organizations' repositories will have one or more protected branches(e.g. master) If you're using git, everyone has a local repo, and that repo's master branch is local: they can rewrite their unpublished content in it however they want. It's really quite convenient; a good feature of git.
dahart 5y ago
What actual reasons do you need to preserve your merge mistake? When will it be needed again, and what for? Why should people who saw it need to see it again later? Do they want to build the code with the mistake, or do they just want the fix? Who is going to look for the mistake? Who is going to complain if they can’t find it? Git doesn’t erase mistakes. It presents a second, separate graph of commits after rebase than before. Both graphs are still there, nothing is erased, and nothing is destroyed. It’s quite important, as a VCS, that nothing is destroyed because it means if I do it wrong, I can undo. > To erase an entry in the financial ledger of a company is fraud. It is a felony. […] I believe that VCSes should be treated similarly. You want people who fix code mistakes to go to jail if they don’t keep a record of the mistake? Why? There’s a very, very good reason that actually lying on financial ledgers is illegal, while quietly fixing a merge mistake is not. You are conflating so many things in this broken analogy that it’s difficult to respond to. Financial ledgers are one of the very few things in the world where history is required by law to be sacrosanct, and companies know this and agree to it in advance. The number of editable things in the world that aren’t expected to preserve history and aren’t illegal are uncountable. Nobody’s going to jail if they erase a bad chapter in a book or movie script. Nobody’s committing a felony if they tear down a house and rebuild it. Nobody is being called a deceitful liar when they erase a mistake on their math test and write down the correct answer. Your belief was not shared by the designers of git (nor of any other DVCS before Fossil). This is the core of why your claims about git are wrong. No promise was ever made to preserve history as it happened, that was never part of the intent in its design. Therefore the very argument that git is being deceitful is a dishonest argument - it’s a projection of your personal goals onto other people and other’s people’s software, not a true story about why git was designed the way it is. The fact that your telling is motivated by trying to convince people to use Fossil over git just makes the hyperbolic framing seem extra cheesy. > If you want to say that commits to your private branches are not part of the permanent record, and that you should therefore be permitted to edit those private branches, then I think you have a stronger case. That is, in fact, the primary use of rebase, by a mile. I’m certain you already know this. Which is a big part of why all the hyperbole about fraud, lying, deceit is ironically not an honest narrative. > Shunning is a mechanism for removing illegal and illegitimate content. So is rebase. Sometimes that’s how it’s used. Maybe it happens, but I’ve never seen public history intentionally rebased other than in emergencies. So what, exactly, is preventing people from using shun for legitimate content day-to-day? Are you policing it’s use?

by SQLite 5y ago

thayne 5y ago

> If you want to say that commits to your private branches are not part of the permanent record, and that you should therefore be permitted to edit those private branches, then I think you have a stronger case. That does not come up as much in Fossil. Fossil does support private branches, but they are seldom used. The usual case in Fossil is that all check-ins auto-sync up to the parent repo. This is probably one of my biggest problems with fossil. It is very opinionated about the workflow you use. My typical workflow involves making many commits on a private branch while working on something, many of which won't be able to build or pass tests, and then clean everything up before pushing to a publicly visible branch. This allows me to easily roll back if an approach ends up not working out, or cherry-pick smaller changes to other branches if a change ends up being needed in multiple feature branches in progress at once, etc. With git that sort of workflow is trivial, with fossil, it might be possible, but it doesn't fit with fossil's blessed workflow. Git on the otherhand is pretty flexible, and can be used for a lot of different workflows, and doesn't push you towards a specific one.

kazinator 5y ago

An automatic merge is just some algorithm's often poor idea of how some parallel changes should be integrated. This has to be verified by a software engineer and put through QA, and adjusted as necessary so that it works to the best of everyone's knowledge. Then you publish the result as the result of the merge. If you commits the result of a merge before doing anything with it to fix it up, that implies that you will sometimes be committing non-buildable code which still contains conflict markers. That's not even allowed under a continuous integration policy that every build has to build (and pass unit tests and whatnot).

TeeMassive 5y ago

As I was reading your comment I caught myself thinking this was a post defending git but then I saw you username. All of what you mention are what git allows to do and also how git is used 99.9% of the time. I can't help but notice your lack of experience with Git, and I say that very respectfully. Most organizations' repositories will have one or more protected branches (e.g. master). What is published there remain. Even mistakes. When the history on those branches are erased it is for very good reasons only. Usually it involves the size of the repository getting too big, illegal / private content and paths only differing by lower and upper case messing with Git on Windows. Even in those very rare cases the history of the vast majority of the files remain. And this is also something all CVS has to face so this is not specific to Git itself. Dev branches are pushed, overwritten and erased. I don't see how that's a problem. In the end having small intelligible commits that reads like a dish recipe accelerates code reviews and corrections and I haven't seen any other VCSes doing that as efficiently as Git.

kazinator 5y ago
> Most organizations' repositories will have one or more protected branches(e.g. master) If you're using git, everyone has a local repo, and that repo's master branch is local: they can rewrite their unpublished content in it however they want. It's really quite convenient; a good feature of git.

dahart 5y ago

What actual reasons do you need to preserve your merge mistake? When will it be needed again, and what for? Why should people who saw it need to see it again later? Do they want to build the code with the mistake, or do they just want the fix? Who is going to look for the mistake? Who is going to complain if they can’t find it? Git doesn’t erase mistakes. It presents a second, separate graph of commits after rebase than before. Both graphs are still there, nothing is erased, and nothing is destroyed. It’s quite important, as a VCS, that nothing is destroyed because it means if I do it wrong, I can undo. > To erase an entry in the financial ledger of a company is fraud. It is a felony. […] I believe that VCSes should be treated similarly. You want people who fix code mistakes to go to jail if they don’t keep a record of the mistake? Why? There’s a very, very good reason that actually lying on financial ledgers is illegal, while quietly fixing a merge mistake is not. You are conflating so many things in this broken analogy that it’s difficult to respond to. Financial ledgers are one of the very few things in the world where history is required by law to be sacrosanct, and companies know this and agree to it in advance. The number of editable things in the world that aren’t expected to preserve history and aren’t illegal are uncountable. Nobody’s going to jail if they erase a bad chapter in a book or movie script. Nobody’s committing a felony if they tear down a house and rebuild it. Nobody is being called a deceitful liar when they erase a mistake on their math test and write down the correct answer. Your belief was not shared by the designers of git (nor of any other DVCS before Fossil). This is the core of why your claims about git are wrong. No promise was ever made to preserve history as it happened, that was never part of the intent in its design. Therefore the very argument that git is being deceitful is a dishonest argument - it’s a projection of your personal goals onto other people and other’s people’s software, not a true story about why git was designed the way it is. The fact that your telling is motivated by trying to convince people to use Fossil over git just makes the hyperbolic framing seem extra cheesy. > If you want to say that commits to your private branches are not part of the permanent record, and that you should therefore be permitted to edit those private branches, then I think you have a stronger case. That is, in fact, the primary use of rebase, by a mile. I’m certain you already know this. Which is a big part of why all the hyperbole about fraud, lying, deceit is ironically not an honest narrative. > Shunning is a mechanism for removing illegal and illegitimate content. So is rebase. Sometimes that’s how it’s used. Maybe it happens, but I’ve never seen public history intentionally rebased other than in emergencies. So what, exactly, is preventing people from using shun for legitimate content day-to-day? Are you policing it’s use?