4 ms·

> Why? What need is there to preserve the commit history, and why is it superior? Being able to lie about what changes took place, what methods might have been

> Why? What need is there to preserve the commit history, and why is it superior? Being able to lie about what changes took place, what methods might have been tried by scrapped, and other small things possibly considered "noise at the time" often end up being valuable clues during maintaining that code years later. >Are you very familiar with git and understand what workflows the git history rewriting tools were intended for, and how they’re typically used and supposed to be used? Yes, intention for the tools, and the way people end up using them are not 1:1. The potential for mistakes and information hiding is higher when you can rewrite history. > Git only ever advocated for rebase, squash, and cherry pick for local branches that haven’t been pushed or shared yet. Just because they advocate using it the right way, they enable using it the wrong way so people will use it the wrong way, and that's a guarantee of humans. >It is arguably not even “history” until you publish it. If you committed it, it's history. If you're trying to make the claim of local history having no utility, thats a different argument imo. > There have always been strong warnings about doing those things to published histories. It’s bad form generally speaking to do it (rebase or change history) to a published branch that more than 1 person is using for any other reason than extreme necessity, such as cleaning up security accidents where someone pushed keys or info they weren’t supposed to. And for exactly that reason, all the opinionated DVCSs that claim to consider history “sacred” actually offer the ability to easily rewrite published history, including Hg and Fossil! This shows your lack of knowledge and XP with other DVCS and your assumptions there. > Git’s ability to rewrite local history is pretty important for (1) encouraging a commit-early commit-often workflow where the local repo is a safe space, No, I can do that with out rebase or cherry pick. (2) cleaning up your work to make it presentable and semantically organized before sharing/publishing, and Bad practice. Your history is useful metadata about what happened. I don't want a single commit in your PR. I want to see the reason it took X days. (3) allowing real-world workflows where people didn’t plan every single feature branch in advance but happened to end up working on multiple things and committing them first. > That's a nonsense claim. > A version control system should be, first and foremost, a safety net that simply backs up any work you do without judgement. Then use Dropbox? >Personally, I consider the idea that commit history is sacred to be dogmatic and unnecessary. I think this shows a lack of XP in maintaining older systems. >I’m open to the idea that it might help prevent a few specific types of accidents here and there, and it might be fair to argue that offering tools to groom the history’s presentation, separately from the log of commit activity, is on average a slightly better idea than having to actually reorganize commits before pushing them. Maybe that didn’t occur to git devs before it was released, or maybe it did and they decided it wasn’t going to help anyone and just add confusion to have two separate timelines. I don’t see any reasons justifying calling git’s design a ‘mistake’, and there seems to be evidence that most people are fine with git, and that for whatever reason the DVCSs that reacted to git in 2005 by immediately trying to fix some of git’s perceived issues didn’t ultimately fix the problem well enough to gain traction. Yes, history grooming is purely something for a UI to do.

dahart 3y ago
> Being able to lie You’ve lost me from the start, this is 100% bad faith argument. This is against HN guidelines too, the mods have confirmed that parroting Dr. Hipp’s hyperbole is not welcome here. The irony is that calling it a “lie” is pure hypocrisy on your part. You already know that rebase wasn’t invented for the purposes of deceiving anyone, and you’re already aware that nobody using git is under the impression that commits won’t get rearranged (rebase is proof of that), nobody is expecting git commit dependencies to represent the historical order events happened in, because that’s not the way git works and not what it was designed to do, which means you are the one lying here. If you don’t know or can’t talk about git’s design in terms of what git designers were actually intending, then Chesterton’s Fence, you don’t get to tear it down. What’s so sad about this is you and other Fossil followers are stuck on the bogus bad faith argument, lowering yourselves to attacking and name-calling, when a good faith argument exists and is just waiting for you to adopt it. You don’t have to repeat this stupid hyperbole. There are good reasons to consider other DVCS designs. There are ways to talk about and justify and sell what Hg and Fossil do without trying to villainize git and git users. For your own sake, and for the sake of setting a better example for other Fossil fans, try to find the strength to shed yourself of the negativity and explain why other systems are better than git while maintaining the stance that git was a good design for it’s time. If you can’t do that, then seriously, consider the possibility that the thing you’re arguing over actually isn’t better.

dahart 3y ago

> Being able to lie You’ve lost me from the start, this is 100% bad faith argument. This is against HN guidelines too, the mods have confirmed that parroting Dr. Hipp’s hyperbole is not welcome here. The irony is that calling it a “lie” is pure hypocrisy on your part. You already know that rebase wasn’t invented for the purposes of deceiving anyone, and you’re already aware that nobody using git is under the impression that commits won’t get rearranged (rebase is proof of that), nobody is expecting git commit dependencies to represent the historical order events happened in, because that’s not the way git works and not what it was designed to do, which means you are the one lying here. If you don’t know or can’t talk about git’s design in terms of what git designers were actually intending, then Chesterton’s Fence, you don’t get to tear it down. What’s so sad about this is you and other Fossil followers are stuck on the bogus bad faith argument, lowering yourselves to attacking and name-calling, when a good faith argument exists and is just waiting for you to adopt it. You don’t have to repeat this stupid hyperbole. There are good reasons to consider other DVCS designs. There are ways to talk about and justify and sell what Hg and Fossil do without trying to villainize git and git users. For your own sake, and for the sake of setting a better example for other Fossil fans, try to find the strength to shed yourself of the negativity and explain why other systems are better than git while maintaining the stance that git was a good design for it’s time. If you can’t do that, then seriously, consider the possibility that the thing you’re arguing over actually isn’t better.