Live data from Hacker News

Fossil Chat

fossil-scm.org

151–160 of 172 posts

Re: Fossil Chat

#151
post #146

Earlier quoted context omitted.

I think (a) all of this was explained clearly in the post by SQLite (Fossil creator), and (b) you're overly sensitive to a disagreement about the definition of terms. I agree with him. You don't. That's fine - no kittens will be put to death depending on who is right.

Hehe, true, no kittens will die. I'm just debating, so don't get overly sensitive just because I disagree. I don't feel like it was clearly explained, which is why I asked those questions. There's no distinction between local private history and public history shared with others, there's no explanation for the arbitrary line drawn on transaction boundaries, or why those are more sacred than other kinds of project his…

Nobody was trying to "induce shame." Your comments on this topic are a special kind of crazy.

Re: Fossil Chat

#152
post #149
post #139

Earlier quoted context omitted.

You shun the secrets-leaking commit: https://fossil-scm.org/home/doc/trunk/www/shunning.wiki

Thanks! So... there's both shun and scrub in Fossil, which lie about project history? Or is is not accurate to call it lying in this case?

I don't know about scrub as it doesn't alter version history but user data such as passwords, IP addresses, etc.; but to shun an artifact definitely meets my criteria for falsifying history and thus lying. I neither suffer from cognitive dissonance nor feel the need to defend a piece of software's honour.

Re: Fossil Chat

#153
post #36
post #32

Earlier quoted context omitted.

Because they're cdevs.

I think you mean cdvs, the e is clearly overkill, takes up more bytes on disk, increases compile times and eats up valuable screen real estate! The last one is especially bad, because it will make the code that uses it harder to read.

yr cmmnt's ndlssly vrbs.

Re: Fossil Chat

#154
post #147
post #141

Earlier quoted context omitted.

In the event it's done before pushing, it's still lying, albeit to yourself—it is falsifying the record of what actually happened. The clearest way of conveying this is with the word "lying." Perhaps "falsifying" or even "manipulating" would also appropriately convey this fact. And conveying facts accurately is arguing in good faith. Not to mention it is not only ever done while contained to the local checkout, in wh…

Why not just focus on the useful idea of separating presentation from commits, as a +1 bit of design thinking and evolution beyond git? I don't get this pretend crusade for nothing more than facts and truth, when the value judgement in the Fossil docs is thick and plain as day. I don't even care that Fossil is attacking the competition, really. I am a huge fan of SQLite. I just wish this silly "lying" argument would…

That's on you that you take it as a value judgment of your or anyone else's character. It's quite literally an accurate description of the rebase feature and the result of its use. And criticism of Git's design philosophy should not be misconstrued as a pretend crusade or personal attack. I presume the lead dev of Fossil and SQLite places a high price on auditability for not only personal philosophical reasons but professional necessity. So highlighting the foible to facilitate falsifying the historical record of a software development lifecycle is fair. But to get so vexed and try to persuade others that an emotional response to an accurate description of a software component is always going to be a tough sell. Instead, maybe try Fossil and see if it is in fact unsuitable to your workflow, then try a different persuasive approach on why Fossil is wrong. Because on this point—it isn't.

Re: Fossil Chat

#155
post #103
post #99

Earlier quoted context omitted.

Agreed. In particular “Rebasing is lying about the project history” is misleading and frankly, just downright lame hyperbole. I actually want to try Fossil, but this text is so dishonest and hyperbolic, it’s off-putting and preventing me from trying Fossil. This feels like a sign that Fossil might not be focused on real world user needs. It’s not uncommon to bump into this claim in threads about git, I don’t think th…

I consider a version control system to be a history of a project. If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact. The history Git and in Fossil is only precise to the transaction level. A key-stroke or backspace is not a transaction. A single iteration of the edit-compile-test cycle is not a transaction. A t…

Huge respect for your work on SQLite.

I can’t say I agree with this though.

> If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact.

I use rebase to clean up the history of my feature branches before merging to release branches.

In that sense I don’t see a moral difference between not committing my work at all until it’s complete and rebasing. It doesn’t seem like any more of a rewriting of history than just editing text before each commit.

The nice thing about rebasing is that future readers don’t need to see the 20 commits I created titled “wip” just so I could back up my work at the end of the day or push to a test server.

Re: Fossil Chat

#156
post #103
post #99

Earlier quoted context omitted.

Agreed. In particular “Rebasing is lying about the project history” is misleading and frankly, just downright lame hyperbole. I actually want to try Fossil, but this text is so dishonest and hyperbolic, it’s off-putting and preventing me from trying Fossil. This feels like a sign that Fossil might not be focused on real world user needs. It’s not uncommon to bump into this claim in threads about git, I don’t think th…

I consider a version control system to be a history of a project. If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact. The history Git and in Fossil is only precise to the transaction level. A key-stroke or backspace is not a transaction. A single iteration of the edit-compile-test cycle is not a transaction. A t…

> I call it "lying", since the purpose seems to be to deceive the reader about what actually happened.

This is exactly the kind of dishonest hyperbole daheart mentioned.

The purpose isn‘t to deceive the reader. Does the reader really need to see the "tmp" commit I made when switching from my desktop to my laptop? I do not think so, and squashing this commit is not intended to deceive anybody. Your comment on the other hand…

In my view, what I am doing with rebase is creating project history, not changing it. The history becomes immutable and "the truth" once the feature branch is merged.

> I think that a source code repository should be a true history of a project.

You repeatedly claim this without justification. Seems like many people do not see the value in "WIP" and "tmp" commits and failed design decisions littering history.

You do provide good reasons for why this isn‘t useful though:

> So you can backspace and edit and change all you want to before typing "commit"

So you agree correcting mistakes is useful, and not everything should be recorded.

> It is useful to have a simplified overview of project history, to aid the reader's comprehension.

> I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative.

Exactly.

Consider "I ate a sandwich." vs "I though about eating a watermelone (typo), but when I opened the fridge, I changed my mind and decided to make a sandwich instead. During the process I dropped my knife on the floor and had to clean it. Then I ate a sandwich."

The second one is a much more detailed and truthful account of what happened, yet it does not provide any value. The first, much shorter and easier to follow, history conveys exactly what I wanted to tell you: What I ate.

Re: Fossil Chat

#157
post #146

Earlier quoted context omitted.

Hehe, true, no kittens will die. I'm just debating, so don't get overly sensitive just because I disagree. I don't feel like it was clearly explained, which is why I asked those questions. There's no distinction between local private history and public history shared with others, there's no explanation for the arbitrary line drawn on transaction boundaries, or why those are more sacred than other kinds of project his…

Nobody was trying to "induce shame." Your comments on this topic are a special kind of crazy.

Of course the article is trying to induce shame; that’s the whole point, to be persuasive that rebase is “harmful”. I believe @SQLite disagrees with you.

“Throwing the word "lying" into an argument like this counts as name-calling and flamebait in the sense that the site guidelines use these terms. It leads to distracting, shallow, and therefore more boring conversation. Would you mind reviewing the rules and please not do that? Let's stay focused on exchanging what we're curious about. https://news.ycombinator.com/newsguidelines.html”

https://news.ycombinator.com/item?id=19886216

Name calling only reflects rather poorly on you, and suggests you aren’t able to articulate a response. I’m not the first or the last person to advocate being more honest on this topic.

Re: Fossil Chat

#158
post #154
post #147

Earlier quoted context omitted.

Why not just focus on the useful idea of separating presentation from commits, as a +1 bit of design thinking and evolution beyond git? I don't get this pretend crusade for nothing more than facts and truth, when the value judgement in the Fossil docs is thick and plain as day. I don't even care that Fossil is attacking the competition, really. I am a huge fan of SQLite. I just wish this silly "lying" argument would…

That's on you that you take it as a value judgment of your or anyone else's character. It's quite literally an accurate description of the rebase feature and the result of its use. And criticism of Git's design philosophy should not be misconstrued as a pretend crusade or personal attack. I presume the lead dev of Fossil and SQLite places a high price on auditability for not only personal philosophical reasons but pr…

https://news.ycombinator.com/item?id=19886216

Re: Fossil Chat

#159
post #152
post #149

Earlier quoted context omitted.

Thanks! So... there's both shun and scrub in Fossil, which lie about project history? Or is is not accurate to call it lying in this case?

I don't know about scrub as it doesn't alter version history but user data such as passwords, IP addresses, etc.; but to shun an artifact definitely meets my criteria for falsifying history and thus lying. I neither suffer from cognitive dissonance nor feel the need to defend a piece of software's honour.

It is interesting that Fossil’s pages on shun and scrub are notably absent of all the negative language that the rebase page contains.

Re: Fossil Chat

#160
post #157

Earlier quoted context omitted.

Nobody was trying to "induce shame." Your comments on this topic are a special kind of crazy.

Of course the article is trying to induce shame; that’s the whole point, to be persuasive that rebase is “harmful”. I believe @SQLite disagrees with you. “Throwing the word "lying" into an argument like this counts as name-calling and flamebait in the sense that the site guidelines use these terms. It leads to distracting, shallow, and therefore more boring conversation. Would you mind reviewing the rules and please…

> Name calling only reflects rather poorly on you

I wonder what name you think I called you, since I didn't call you a name.

> Of course the article is trying to induce shame

Okay, Captain Crazy. (there: that's what name calling looks like)

> “Throwing the word "lying" into an argument like this counts as name-calling and flamebait in the sense that the site guidelines use these terms. It leads to distracting, shallow, and therefore more boring conversation. Would you mind reviewing the rules and please not do that?

So, this is also crazy, but interesting. I noticed in the above thread that Richard accused a git feature of "lying," which is something a sane person would not take personally, and you absurdly accused him of lying, and apparently you view this as somehow a useful tit-for-tat instead of the terrible behavior it is.

But this is delusion. I didn't use the word lying at all, so I wonder what the heck you're even talking about. It's not your honesty or lack thereof that is striking or interesting enough to comment on, it's your bizarre defensiveness about features and documentation, to the point of attacking people who certainly mean well.

Post reply on HN