Keshl has joined #forth
dave0 has quit [Quit: dave's not here]
f-a has quit [Quit: leaving]
Zarutian_HTC has joined #forth
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
Lord_Nightmare has quit [Quit: ZNC -]
Lord_Nightmare has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
dave0 has joined #forth
gravicappa has joined #forth
gravicappa has quit [Ping timeout: 272 seconds]
gravicappa has joined #forth
<siraben> f-menagr-a-mo: I use Git and it's very nice IMO
<siraben> though for personal/smaller projects sometimes no VC at all
<proteusguy> I use git. I hate it. Never will you find the occasion to use the default parameters to do anything useful. But it's won the market share without question. The best designed one, imho, is mecurial.
sts-q has quit [Ping timeout: 240 seconds]
<siraben> proteusguy: what do you dislike about git?
sts-q has joined #forth
<siraben> dunno if mercurial has it but one feature I use all the time is git rebase which makes it painless to rewrite history
djinni has quit [Ping timeout: 260 seconds]
proteus-guy has joined #forth
djinni has joined #forth
<patrickg> I guess long-term mercurial might have a future as a friendlier frontend to git repos:
_whitelogger has joined #forth
hosewiejacke has joined #forth
clog has quit [Ping timeout: 256 seconds]
dys has left #forth ["Killed buffer"]
dys has joined #forth
wineroots has quit [Ping timeout: 240 seconds]
gravicappa has quit [Ping timeout: 264 seconds]
xek has joined #forth
clog has joined #forth
<proteus-guy> patrickg, oh right i forgot all about that. I should consider adopting it.
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-guy has joined #forth
<veltas> Also interested to know what's good about Mercurial
<veltas> But unlikely to change because git works fine for me, and I like GitHub despite all its flaws
<veltas> Interested to know exactly what's so *bad* about git, for one thing
<siraben> Yeah
<nihilazo> to me git is just confusing to use
<patrickg> git is somewhat more open about its internals than most other VCSes, which both allows for more power but also adds confusion when all you want to do is manage the history of a few files.
<siraben> nihilazo: how so?
<nihilazo> as soon as I want to do something more complex than just add, commit, push, I have to spend a while looking through manpages and searching stackoverflow for how
<patrickg> once you used git in anger for a year or so these things become second nature, but that's not a typical learning curve for a tool ;-)
dave0 has quit [Quit: dave's not here]
<nihilazo> I've been using it for longer than that lol
<siraben> BTW magit makes working with Git pretty painless
iyzsong has quit [Quit: ZNC 1.7.5 -]
<patrickg> the downside is that magit requires emacs ;-)
<patrickg> but yes, there are alternative user interfaces, but the main entry point remains the git cli
<siraben> within a few weeks of actually using it beyond push/pull/commit I felt proficient with Git, so I guess it depends
<siraben> rebase, cherry-pick, bisect are some pretty nice features, and Git is very careful about not deleting unreachable objects/commits
<veltas> I've never sat down and tried to "learn git properly", and instead just try and understand the commands I need when I google for them, if it's not very basic management. I've never used a VCS I haven't had to google help with, and git at least has the most help online for it.
<patrickg> I have no issues with git myself (and was surprised when I recently used monotone again after ~10 years of non-use how much I adapted to git), but I remember being confused by its differences to ~everything else (and I used a lot of different VCS over the years)
<veltas> Like with perforce you'll google for help and get nothing, if you're lucky someone will explain a cryptic addressing mechanism that lets you do half of what you need and that suffices most times
<siraben> Should I bother learning other VCS? Sounds like the switching cost is high
<veltas> patrickg: The thing is that mercurial seems to be quite similar to git in its model, the main difference I see from trying to look online is git has more control over how you stage stuff, and the way that merges are handled in branch logs
<veltas> siraben: I don't think the switching cost would be high, the reason I don't bother is what do I gain?
<veltas> It seems like it's for nothing
<siraben> right. exactly 0 projects I've contributed to used something other than git
<veltas> The only other thing I see people use is subversion, if the project is old enough to have been started before git was mainstream
<veltas> In open source, anyway. In companies you see a lot of perforce
<patrickg> my main project (coreboot) migrated from subversion to git 10 years ago, and it started before git was a thing (we started with CVS). On the way I made some collaborators also try gnu arch (before it was gnu), monotone, svk (some subversion extension for distributed work) and a few other things, but it became clear early-on that git will win out. That's a huge argument
<patrickg> it was the only argument in its favor though ;-)
f-a has joined #forth
gravicappa has joined #forth
proteus-guy has quit [Ping timeout: 240 seconds]
<proteusguy> siraben, there's really not much reason to learn another SCS once you know git. Most are pretty bad anyway and git is universal nowadays.
<f-a> there is a good reason: some of them offer a more pleasant UX than git
<f-a> I am always amazed at how painless darcs is, cherrypicking for everything
<f-a> sadly, git is the only one which is battle tested for gigantic software
f-a has quit [Quit: bb]
<proteusguy> f-a outside of mercurial, which one outside of git do you think that a pleasant UX? And mercurial actually scales better than git.
elioat has joined #forth
* crc uses fossil, but is providing read-only git mirrors of his public repos
<proteusguy> crc, I'm not familiar at all with fossil. This something new?
<crc> repo is stored in an sqlite3 database; has a single binary that handles everything
<elioat> I'm also a fan of fossil
<elioat> never used it on a collaborative project, but for my hobby stuff it is my go-to choice typically
<proteusguy> crc, yikes! sqlite is the opposite of fixed and never to be deleted forever! dunno that I'd trust that for VCS.
<veltas> sqlite is a good project and it is actually very stable
<veltas> If I had to choose between a btrfs driver and sqlite for integrity I'd choose sqlite
<proteusguy> veltas, no arugument there - but it's designed to allow updates and deletions of data. Also, it can lose data in a process failure.
<veltas> News to me
<mstevens> I've used perforce commercially and always liked it. I've never heard anything bad about mercurial.
<proteusguy> Ah - I just checked and sqlite does now have a writeahead log. So I guess if you have that going a process failure is still recoverable.If you don't have that going then you can lose data.
<proteusguy> mstevens, I used perforce years ago before good open source tools were available. I liked it. But I prefer distributed models now.
<veltas> I hate the way it makes files read-only by default
<mstevens> proteusguy: This is where my experience is a bit limited, I used it pre-git, I believe they've tried to compete and come out with a distributed product, but I don't know anything about it.
<proteusguy> mstevens, it was definitely one of if not these best commercial ones.
<veltas> I'd use (and do) git over perforce in a commercial setting
<proteusguy> veltas, re:read-only by default - you talking about perforce?
<veltas> Yes
<proteusguy> veltas, yes that's because it follows the pvcs model of locking files before modifying them. totally old school. :-)
<mstevens> These days I use git because it's good enough and it's nearly universal, but I don't actually like it.
<proteusguy> mstevens, yep agreed - git has pretty much just won. resistance isn't worth it. it's not that hard to get it but it is entirely unnatural, alas. But it certainly is powerful and works.
<veltas> proteusguy: It's for old-school performance reasons that don't apply anymore, meanwhile it performs worse in practice than basic operations than git does.
<proteusguy> veltas, oh yeah - the pessimistic locking model is obsolete. very "enterprisey". But it was a strong tool in its day.
<mstevens> proteusguy: A friend works with mercurial and uses the git extension to interface with the rest of the world, I've not tried it but that might give you the best of both worlds.
<proteusguy> mstevens, yes I need to give that a shot.
<proteusguy> veltas, interesting that two examples of how sqlite can lose data were actually using fossil as their examples.... yipes! ;-)
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
<veltas> I find it trustworthy that they document how they have failed, give examples, and also it seems unlikely any of those issues will ever affect me.
<veltas> Nothing should ever cause serious data loss, because you should *never* use a VCS without backups
<veltas> But obviously data integrity is important to the extent I don't ever expect to have to deal with data integrity issues from my VCS, and with fossil it appears I am still unlikely to experience it myself
Zarutian_HTC has quit [Ping timeout: 260 seconds]
Zarutian_HTC has joined #forth
f-a has joined #forth
<siraben> proteusguy: which aspects of mercurial scale better than git?
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
elioat has quit [Quit: elioat]
hosewiejacke has quit [Ping timeout: 256 seconds]
gravicappa has quit [Read error: Connection reset by peer]
f-a has quit [Quit: leaving]
elioat has joined #forth
gravicappa has joined #forth
Keshl has quit [Read error: Connection reset by peer]
Keshl has joined #forth
f-a has joined #forth
hosewiejacke has joined #forth
hosewiejacke has quit [Remote host closed the connection]
dys has quit [Remote host closed the connection]
dys has joined #forth
kiedtl\x1b has joined #forth
gravicappa has quit [Ping timeout: 240 seconds]
f-a has quit [Ping timeout: 256 seconds]
f-a has joined #forth
elioat has quit [Quit: elioat]
elioat has joined #forth
elioat has quit [Quit: elioat]
inode has quit [Quit: ]
<f-a> see interpret
<f-a> : interpret useraddr <64> @ >r 140465469356744 catch r> useraddr <64> ! throw ; ok
<f-a> what is <64> ?
xek has quit [Ping timeout: 256 seconds]
<lispmacs[work]> f-a: I don't quite have the full answer to your question, but in gforth source, useraddr is definied in the `prim' file as ( #u -- a_addr ). My guess is that <64> is definied at gforth compile time as user address space memory localation or something similar, and useraddr turns that into an address in a word
<MrMobius> its not saying useraddr is a 64 bit address?
<f-a> oh
<f-a> ohhhhhh
<f-a> I see, effective behaviour
f-a has quit [Quit: leaving]
sts-q has quit [Quit: ]
sts-q has joined #forth
scoofy has quit [Ping timeout: 265 seconds]
scoofy has joined #forth