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

111–120 of 172 posts

Re: Fossil Chat

#111

Post by harryvederci »

SQLite wrote: post #103
dahart wrote: 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…

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, man! There is no need to speak negatively about the behaviour of other players if you're a fantastic player yourself. I'd personally just mention: "Git allows you to change history. Fossil is never going to allow changing history, because that could cause issues X, Y and Z. If you do need to change history for some reason, by all means try something like Git." Keep it factual, and get right back to pointing out what makes Fossil great.

I love how SQLite doesn't downplay any alternatives, it just says: "Look at me. I'm awesome. But if you need to do , you probably don't want to use me." It would be great if the Fossil website had that same awesome attitude.

TL/DR: Random guy X that never created a successful product gave marketing advice to the person who created one of the most successful products of all time. Random guy X is an idiot.

Re: Fossil Chat

#112

Post by NoodleIncident »

wyoung2 wrote: post #58
scambier wrote: post #25

Earlier quoted context omitted.

Most Fossil projects are on the smaller (smallest?) side, apart from 2-3 outliers. They certainly don't have a dedicated IM channel, and they certainly don't need it... except when they do. I could see this as a useful feature when you need to chat with contributors once in a while in a less-formal way than issue comments.

Yes. Developers working independently is best for productivity, but sometimes you need to coordinate something, which then brings up the question: what to use? The last time I tried to list it, I came up with over a dozen options, all of which either require some sort of admin setup hassle or put you into the claws of some megacorp. With Fossil chat, you've already got Fossil set up, so it becomes the low-friction pa…

I forsee an addition to this diagram with "the chat tab of a shared fossil repo", as one of the completely isolated bubbles to the side

https://xkcd.com/1810/

Re: Fossil Chat

#113

Post by dahart »

SQLite wrote: post #103
dahart wrote: 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.

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 of history, one un-editable for details and one editable for presentation. That’s interesting and useful. Instead you choose to take cheap shots at a system that was designed differently than your ideal, without acknowledging its intent. You are breaking Hanlon’s razor and consciously choosing to assuming malice... for something that has a written history of discussion about why it exists.

Are you aware that rebase openly advertises the fact that it reorders commits, and was designed that way intentionally? Are you aware that git openly makes zero guarantees about the order of transaction events, intentionally, to allow me to have control over my presentation? Are you aware that rebase is primarily used on local commits before push, and not often used after push?

I would speculate that you are aware of these things, and not simply ignorant about git. If so, that means you are lying here and now, if not it means you don’t know what you’re talking about. I think you know git’s design intent, so it seems like you are intentionally misrepresenting the design intent of rebase. The only deceit here is coming from you, ironically.

Re: Fossil Chat

#114

Post by dahart »

harryvederci wrote: post #111
SQLite wrote: post #103

Earlier quoted context omitted.

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…

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…

Well said. Exactly. I agree 100%.

> I never understood why people want to change commit history in Git

FWIW, by and large, they don’t, not after it’s been pushed. That’s one of the major problems with this critique.

Re: Fossil Chat

#115

Post by [deleted] »

rubyist5eva wrote: post #34
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.

This is what private branches are for - when you merge them and sync they show up as a single commit on the mainline branch - not too different from git merge --squash.

[deleted]

Re: Fossil Chat

#116

Post by justin66 »

SQLite wrote: post #103
dahart wrote: 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…

Thanks for explaining the rationale of that feature (or lack thereof) here.

Also for the online Fossil docs, which are great.

Re: Fossil Chat

#117

Post by samatman »

exDM69 wrote: post #35
danpalmer wrote: post #8

> Fossil chat is not intended as a replacement or competitor for So what is it for? If it's another inbox to check that's a bit of a productivity drain. I could understand if it was explicitly designed to compete with other chat platforms. This would seem to fit with Fossil's mission well.

Fossil is offline. You sync up when connected and then you have code, issues, wiki, chat that work offline, and sync when connected again. It's not an instant messenger, more like a mail box or a bulletin board. Which works when network is down.

Agh this is a weird combination of accurate and not.

Fossil works offline! But leaving a local server up is pretty normal, and that way you get new stuff just as soon as other servers publish it.

Also, and unique to fossil, the server is just... fossil, same fossil that runs locally. No Gogs, no Gitlab, just your fossil, their fossil, and fossil on the server, maybe with a "real" webserver in front of it, maybe not.

The chat room is clearly intended to be run on an always-on server instance, but there's nothing stopping you from setting it up locally and inviting people to jump on your IP. Well, NAT might well be stopping you... but in principle!

Re: Fossil Chat

#118

Post by bch »

sigzero wrote: post #12
exikyut wrote: post #9

Earlier quoted context omitted.

Ah, due to (who would've thunk) the SQLite connection.

That probably had a lot to do with it I am sure.

> Ah, due to (who would've thunk) the SQLite connection.

The “SQLite connection” is manifold - indeed drh (SQLite author) used to be on the Tcl Core Team, and is an unapologetic user of Tcl. SQLite itself isn’t just “well-supported” in Tcl, it started there. drh calls SQLite “a tcl extension that escaped into the wild”, among other things, and that “...SQLite is still heavily dependent upon TCL and the ongoing support, maintenance, and enhancement of SQLite would not be possible without TCL, and would be seriously inconvenienced without Tk.” [0][1]

The ties are interesting and deep.

[0] https://sqlite.org/tclsqlite.html

[1] https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.htm...

Re: Fossil Chat

#119

Post by bachmeier »

harryvederci wrote: post #111
SQLite wrote: post #103

Earlier quoted context omitted.

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…

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 cheeseburger and they give you a chicken sandwich, maybe it doesn't bother you since you like both, but it would indeed be lying if someone asks what you're eating and you say it's a cheeseburger.

Re: Fossil Chat

#120

Post by mscrnt »

dahart wrote: post #113
SQLite wrote: post #103

Earlier quoted context omitted.

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. 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.
Post reply on HN