04:36 <siraben> f-menagr-a-mo: I use Git and it's very nice IMO

04:36 <siraben> though for personal/smaller projects sometimes no VC at all

04:54 <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.

04:55 <siraben> proteusguy: what do you dislike about git?

05:07 <siraben> dunno if mercurial has it but one feature I use all the time is git rebase which makes it painless to rewrite history

06:25 <patrickg> I guess long-term mercurial might have a future as a friendlier frontend to git repos: http://hg-git.github.io/

10:17 <proteus-guy> patrickg, oh right i forgot all about that. I should consider adopting it.

11:02 <veltas> Also interested to know what's good about Mercurial

11:03 <veltas> But unlikely to change because git works fine for me, and I like GitHub despite all its flaws

11:04 <veltas> Interested to know exactly what's so *bad* about git, for one thing

11:05 <siraben> Yeah

11:07 <nihilazo> to me git is just confusing to use

11:07 <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.

11:07 <siraben> nihilazo: how so?

11:07 <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

11:07 <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 ;-)

11:08 <nihilazo> I've been using it for longer than that lol

11:08 <siraben> BTW magit makes working with Git pretty painless

11:08 <patrickg> the downside is that magit requires emacs ;-)

11:08 <patrickg> but yes, there are alternative user interfaces, but the main entry point remains the git cli

11:08 <siraben> within a few weeks of actually using it beyond push/pull/commit I felt proficient with Git, so I guess it depends

11:09 <siraben> rebase, cherry-pick, bisect are some pretty nice features, and Git is very careful about not deleting unreachable objects/commits

11:10 <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.

11:10 <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)

11:11 <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

11:14 <siraben> Should I bother learning other VCS? Sounds like the switching cost is high

11:14 <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

11:14 <veltas> siraben: I don't think the switching cost would be high, the reason I don't bother is what do I gain?

11:14 <veltas> It seems like it's for nothing

11:14 <siraben> right. exactly 0 projects I've contributed to used something other than git

11:15 <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

11:15 <veltas> In open source, anyway. In companies you see a lot of perforce

11:19 <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

11:21 <patrickg> it was the only argument in its favor though ;-)

13:18 <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.

13:19 <f-a> there is a good reason: some of them offer a more pleasant UX than git

13:19 <f-a> I am always amazed at how painless darcs is, cherrypicking for everything

13:19 <f-a> sadly, git is the only one which is battle tested for gigantic software

13:27 <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.

13:36 <proteusguy> crc, I'm not familiar at all with fossil. This something new?

13:38 <crc> https://fossil-scm.org/

13:38 <crc> repo is stored in an sqlite3 database; has a single binary that handles everything

13:42 <elioat> I'm also a fan of fossil

13:43 <elioat> never used it on a collaborative project, but for my hobby stuff it is my go-to choice typically

13:45 <proteusguy> crc, yikes! sqlite is the opposite of fixed and never to be deleted forever! dunno that I'd trust that for VCS.

13:46 <veltas> sqlite is a good project and it is actually very stable

13:46 <veltas> If I had to choose between a btrfs driver and sqlite for integrity I'd choose sqlite

13:46 <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.

13:47 <veltas> News to me

13:49 <mstevens> I've used perforce commercially and always liked it. I've never heard anything bad about mercurial.

13:49 <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.

13:49 <veltas> https://www.sqlite.org/howtocorrupt.html

13:50 <proteusguy> mstevens, I used perforce years ago before good open source tools were available. I liked it. But I prefer distributed models now.

13:50 <veltas> I hate the way it makes files read-only by default

13:50 <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.

13:51 <proteusguy> mstevens, it was definitely one of if not these best commercial ones.

13:51 <veltas> I'd use (and do) git over perforce in a commercial setting

13:51 <proteusguy> veltas, re:read-only by default - you talking about perforce?

13:52 <veltas> Yes

13:52 <proteusguy> veltas, yes that's because it follows the pvcs model of locking files before modifying them. totally old school. :-)

13:52 <mstevens> These days I use git because it's good enough and it's nearly universal, but I don't actually like it.

13:53 <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.

13:53 <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.

13:54 <proteusguy> veltas, oh yeah - the pessimistic locking model is obsolete. very "enterprisey". But it was a strong tool in its day.

13:55 <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.

13:56 <proteusguy> mstevens, yes I need to give that a shot.

14:11 <proteusguy> veltas, interesting that two examples of how sqlite can lose data were actually using fossil as their examples.... yipes! ;-)

14:20 <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.

14:21 <veltas> Nothing should ever cause serious data loss, because you should *never* use a VCS without backups

14:21 <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

16:58 <siraben> proteusguy: which aspects of mercurial scale better than git?

21:06 <f-a> see interpret

21:06 <f-a> : interpret useraddr <64> @ >r 140465469356744 catch r> useraddr <64> ! throw ; ok

21:06 <f-a> what is <64> ?

22:18 <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

22:19 <MrMobius> its not saying useraddr is a 64 bit address?

22:21 <f-a> oh

22:21 <f-a> ohhhhhh

22:21 <f-a> I see, effective behaviour