Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil Chat

fossil-scm.org

Post reply on HN
Print view View original

121–130 of 172 posts

Re: Fossil Chat

#121

Post by mscrnt »

emodendroket wrote: post #20
HeckFeck wrote: post #2

Does anyone use Fossil? I'm considering it for my personal projects. I like all it offers for the relatively low resource usage. The only use of it I've seen in the wild is Ripcord ( https://dev.cancel.fm/issues ), which is interestingly also relatively low resource usage compared to its competitor.

It seems to me like you’d want it to be obviously way superior for some reason to go so far away from the herd.

You’d forsake an improvement for the sake of following the rest of the cattle? Have you used it, yet, to see if it sufficiently meets your way superior standard to break free from the herd?

Re: Fossil Chat

#122

Post by chillfox »

bachmeier wrote: post #119
harryvederci wrote: post #111

Earlier quoted context omitted.

Big fan of SQLite here (thank you!), and very interested in Fossil as well. I never understood why people want to change commit history in Git, so for me it won't be an issue to not have that in Fossil. Having said that, one point of feedback on the "lying" part: I personally interpret that type of negative phrasing as pointing at a different tool and saying: "Look! They're doing it wrong!" You make amazing tools, ma…

> There is no need to speak negatively about the behaviour of other players I don't interpret it as a negative statement about Git or any other version control system. I interpret it as a statement about use of the term "project history" after rebasing. I agree with him, because the phrase "history of the project" implies it's the history of the project, and that's simply not what you have. If you order a cheeseburge…

Off topic:

I once ordered a cheeseburger and got a “burger” without a beef patty or any other kind of meat, not even the veggie pretend meat. Just bread, sauce, pickles and a single slice of cheese.

I felt pretty disappointed with that “cheeseburger”.

Anyway, my point is that the real world lying about cheeseburgers situation is a lot worse than pulling a fast one and handing over a chicken sandwich.

I would begrudgingly have accepted a chicken sandwich.

Re: Fossil Chat

#123

Post by dahart »

mscrnt wrote: post #120
dahart wrote: post #113

Earlier quoted context omitted.

> I call it "lying", since the purpose seems to be to deceive the reader about what actually happened. Do you have any better reasons to avoid rebase that don’t depend on your own negative interpretation of git’s design intent, an interpretation that contradicts git documentation? You could be focusing on positives instead of trash talking. You could be talking about the interesting idea of providing multiple views o…

Except none of that refutes the fact that changing history is lying irrespective of the motivation behind the change. You can rephrase it however your sensibilities like, it won’t change that fact.

Why are you calling it “lying”? That’s a framing with a value judgement that is accusing people who rebase of being malicious. Do you believe use of rebase is malicious?

Who are you lying to, if the other people on your team expect your merges to be rebased before you push?

What history is being lied about, if no one every saw if before it was pushed, and it is never rebased after being pushed?

Rebase is not intending to trick someone, it is not concealing a truth that needs to be otherwise preserved. Rebase is not hiding something that should not be hidden. Rebase is for cleanup and fixing mistakes.

Please stop using inappropriate words. It’s completely fine to preserve your messy edit history. It’s completely fine to want to preserve your mess. But it is not “lying” to clean it up before you push.

It’s funny you suggest I’m rephrasing it, when you are the one using different (negative) language than the git manual.

Re: Fossil Chat

#124

Post by dahart »

bachmeier wrote: post #119
harryvederci wrote: post #111

Earlier quoted context omitted.

Big fan of SQLite here (thank you!), and very interested in Fossil as well. I never understood why people want to change commit history in Git, so for me it won't be an issue to not have that in Fossil. Having said that, one point of feedback on the "lying" part: I personally interpret that type of negative phrasing as pointing at a different tool and saying: "Look! They're doing it wrong!" You make amazing tools, ma…

> There is no need to speak negatively about the behaviour of other players I don't interpret it as a negative statement about Git or any other version control system. I interpret it as a statement about use of the term "project history" after rebasing. I agree with him, because the phrase "history of the project" implies it's the history of the project, and that's simply not what you have. If you order a cheeseburge…

What history, exactly, is being preserved? If I fix a bug before I commit, then I’m okay. If I commit the bug, then commit the fix, then squash, all locally on my own machine before I push anything, I’m “lying”?

You don’t want the ability to edit your own mistakes before showing them to other people, even if you find them before you push?

Fossil is not capturing my pre-commit keystrokes, so I can write code and delete it without turning it into a ‘transaction’. Is that lying?

What’s sacred about my local branch before I push? In practice, nobody rebases things in public branches except by accident or to fix big mistakes. Rebase is almost entirely a local pre-push workflow. Why should I be preserving my local pre-push history, and why are you calling that “project history”?

If “project history” is so sacred that all commits should be declared immutable, how do you suggest fixing accidents like someone checking in SSH keys? Is it impossible to fix security accidents in Fossil? If so, is that good?

Why is the word “lying” being used instead of saying something like “the project’s history of transactions is being changed”? Do you think the phrasing is not intentional? Do you believe it’s good faith to accuse tool writers and tool users of being deceitful for just using a tool the way it’s designed? Do you believe the write up on rebase is impartial?

Re: Fossil Chat

#125

Post by minusf »

dahart wrote: post #123
mscrnt wrote: post #120

Earlier quoted context omitted.

Except none of that refutes the fact that changing history is lying irrespective of the motivation behind the change. You can rephrase it however your sensibilities like, it won’t change that fact.

Why are you calling it “lying”? That’s a framing with a value judgement that is accusing people who rebase of being malicious. Do you believe use of rebase is malicious? Who are you lying to, if the other people on your team expect your merges to be rebased before you push? What history is being lied about, if no one every saw if before it was pushed, and it is never rebased after being pushed? Rebase is not intendin…

nah, rebasing is white lies. everybody is in on it. not all lies are malicious.

rebasing is "rewriting history". where I'm from "rewriting history" is lying..

Re: Fossil Chat

#127

Post by dahart »

minusf wrote: post #125
dahart wrote: post #123

Earlier quoted context omitted.

Why are you calling it “lying”? That’s a framing with a value judgement that is accusing people who rebase of being malicious. Do you believe use of rebase is malicious? Who are you lying to, if the other people on your team expect your merges to be rebased before you push? What history is being lied about, if no one every saw if before it was pushed, and it is never rebased after being pushed? Rebase is not intendin…

nah, rebasing is white lies. everybody is in on it. not all lies are malicious. rebasing is "rewriting history". where I'm from "rewriting history" is lying..

> not all lies are malicious

The Fossil manual is pretty clear about calling it deceit. “By discarding parentage information, rebase attempts to deceive the reader about how the code actually came together.”

> where I’m from “rewriting history” is lying...

What history? Rebase is normally used before push. Rebase is used before it’s “history” to someone other than yourself.

Re: Fossil Chat

#128

Post by pumpkinhead »

rkeene2 wrote: post #71

I think this is great. I will upgrade ChiselApp.com to use Fossil 2.15 as soon as it's released. A bit off-topic, but the thing I miss most when I use Fossil (versus GitHub.com) is the ability to do code reviews and leave in-line comments on code. Also, pull requests [0] would be awesome for some of my more public projects. [0] https://fossil-scm.org/forum/forumpost/01d77b7259ea0b00b7065...

Thanks again for your work. I very much appreciate chisel.

Re: Fossil Chat

#129

Post by sgbeal »

j-pb wrote: post #106
exikyut wrote: post #33

HI! What it looks like: https://imgur.com/a/PaHExsp Here's Fossil 2.15 running on EC2: http://54.79.202.57/register - this link will allow you to create a new account. Alternatively, the "chat" user (password "chat") can be used if you don't want to make an account. [It used to have the ability to create additional users (with admin privs), with the result that the fossil instance rapidly began spouting SQL errors an…

I don't understand why these tools always have so much styling, when they would look a lot better if they just never did it in the first place. Drop-shadows, rounded corners, borders, colouring, fades. All extra work, all a pain to look at. Is like watching Picasso paint a painting on a glass wall, the first half you're "wow this is great", and then you just want to start screaming "STOP! NO! IT WAS BETTER BEFORE!"

> Drop-shadows, rounded corners, borders, colouring, fades. All extra work, all a pain to look at.

i have it on exceedingly good authority (as the one who implemented it) that the look and feel was about 90% personal preference and 10% feedback from other project members during development. The "extra work" you mention is relative - with modern browser dev tools such things can (with a bit of CSS know-how) often be completely styled in a matter of minutes, then copy/pasted over into CSS. The much more time-consuming part was getting the messages to pop up from the bottom, but the difference in readability between that and top-down posts made that effort well worth it.

There's obviously no accounting for taste, but (A) you're the first person i've seen actually complain about the CSS styles and (B) any given fossil site can restyle be restyled to do its admins' personal tastes - they're not stuck with mine.

Re: Fossil Chat

#130

Post by dahart »

BeetleB wrote: post #104
Hendrikto wrote: post #30

Earlier quoted context omitted.

Fossil looks very interesting, but I completely disagree with their [stance on rebasing]( https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md ). This is a dealbreaker for me. I do not consider having 10 buggy commits per feature instead of 1 working one an advantage. It just complicates reading history and hinders debugging (e.g. bisect). I get their arguments, I just disagree.

First, it sounds like you're looking for squash - not rebase. This is a false dichotomy. You can have it both ways - git just doesn't provide it both ways. In Mercurial, you can squash commits so the history shows it as one commit, but you can still see the individual commits if you really want to. The history is never lost. I imagine Fossil does something similar. Looking at this subthread: Wow! People really get tr…

I guess you’re referring to me, and I guess it’s fair. It has nothing to do with git though, I’m triggered when it comes to arguments that I feel like aren’t being made in good faith.

Serious question though: what do you do in Mercurial, or Fossil, when someone accidentally checks in SSH keys? I’ve watched this happen in companies multiples times.

Post reply on HN