Live data from Hacker News

Sourcehut welcomes Bitbucket refugees

sourcehut.org

211–219 of 219 posts

Re: Sourcehut welcomes Bitbucket refugees

#211
post #58

Earlier quoted context omitted.

But it's not standalone so everyone can use it privately, it only works for your service.

If it's open source then surely you, or someone, could modify it for other services. Moaning when someone gave you free apples because you want apple pie; maybe make your own pastry.

I'm moaning because someone wants to sell me their entire apple tree in order to get the free apple pie while I would be happy to get a few apple to make my own. The service is deeply connected to SirCmpwns paid service and an obvious spam bait.

Re: Sourcehut welcomes Bitbucket refugees

#212

Earlier quoted context omitted.

Finding a decent GUI is definitely the biggest pain point in switching to git for us. It's not just that git GUIs are lacking generally, it's that there's fragmentation - the best ones on one OS don't necessarily work on other OSs. Tortoisehg was so universal that it practically was mercurial, for the purposes of many users. We are scientists and wanting to attract contributions to our code from other scientists and…

Am I the only person who uses gitk and doesn't have any real problems with it?

I used it previously. But it doesn't support a lot of operations, it's mostly good for visualising what's happening while you do your work in the command line.

Re: Sourcehut welcomes Bitbucket refugees

#213
post #87
post #74

Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

Now, I am not a programmer so I get to chose my tools all by myself without any peer preassure. In my early days I managed to destroy quite a lot (as in: counted in hours) of work with git. I switched to hg at the same time as my source control usage became more advanced, and I haven't managed to fuck anything up since. Now, I last used git extensively in 2011, and I have heard things have gotten better on the UX fro…

No offense meant, and I appreciate the anecdote, but I don’t feel that skill level in the technology should indicate the usefulness of the technology. I’m trying to understand more objectively than that.

Re: Sourcehut welcomes Bitbucket refugees

#214

Earlier quoted context omitted.

The ones that usually flock to platforms. Course then you have classic reddit and 4chan which had pretty simple designs.

I changed back to old Reddit recently, and hell yeah the site is a lot more usable. The new version often had severe lag when loading comments, but I don’t have this anymore.

Its an unecessary single page abomination. Reddit will always be popular it doesnt need a new design. The best part was that different communities could style their subs.

I also remember when you could register without an email.

Re: Sourcehut welcomes Bitbucket refugees

#215
post #213
post #87

Earlier quoted context omitted.

Now, I am not a programmer so I get to chose my tools all by myself without any peer preassure. In my early days I managed to destroy quite a lot (as in: counted in hours) of work with git. I switched to hg at the same time as my source control usage became more advanced, and I haven't managed to fuck anything up since. Now, I last used git extensively in 2011, and I have heard things have gotten better on the UX fro…

No offense meant, and I appreciate the anecdote, but I don’t feel that skill level in the technology should indicate the usefulness of the technology. I’m trying to understand more objectively than that.

Judging from other stories, I am not alone. It seems to be a fairly typical story, even with people that use git in a professional setting. I never got comfortable using git after that, and my use case has mostly been to pull, branch, merge, push and the likes. Whenever something happens I have someone to ask, which also seems to be a common thing. A "git guy" you contact when things go wrong.

With mercurial and darcs I never had that happen. Losing code is a deadly sin for a SCM should be behind at least 2 confirmation dialogues.

Whenever pijul reaches 1.0 I will probably switch to that. It seems like patch theory done right.

Re: Sourcehut welcomes Bitbucket refugees

#216
post #162
post #74

Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

We're currently migrating all of our mercurial repos to git. The migration is trivial and retains the full history. After working with mercurial for the last four years, I don't think it offers anything that git doesn't. I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics). Integration with third-party tools and ser…

I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics)

Not true.

Out of the box with no extensions required, Mercurial supports bookmarks, which are functionally the same as Git's branches. Also, Mercurial supports even lighter branching compared to Git using anonymous branches.

This blog post from 2009 explains it all: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

Re: Sourcehut welcomes Bitbucket refugees

#217
post #74

Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

The consensus seems to be that mercurial has a cleaner UI (options and arguments). I also read that it can get slower than git on huge repositories but I don't have benchmarks.

I also read that it can get slower than git on huge repositories but I don't have benchmarks.

Not true. In fact, Mercurial is faster than Git on huge repositories; just ask Facebook--the entire Facebook application lives in a Mercurial mono repository, which wasn't possible without Git slowing to a crawl: https://engineering.fb.com/core-data/scaling-mercurial-at-fa...

Turns out it's been easier for Facebook and others to optimize Mercurial over the years due to it being 95% Python, which is easier to refactor.

And because of Mercurial's extensibility, it's easier to replace or optimize different components.

Re: Sourcehut welcomes Bitbucket refugees

#218

Earlier quoted context omitted.

Same, but users think it's ugly and doesn't look "right" or "modern" :/

Lesson learnt: don't listen to all users, have confidence in some of your decisions...

Haha who do you think makes the final call? Executives (i.e. users) or the IT Department?

Re: Sourcehut welcomes Bitbucket refugees

#219
post #162

Earlier quoted context omitted.

We're currently migrating all of our mercurial repos to git. The migration is trivial and retains the full history. After working with mercurial for the last four years, I don't think it offers anything that git doesn't. I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics). Integration with third-party tools and ser…

I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics) Not true. Out of the box with no extensions required, Mercurial supports bookmarks, which are functionally the same as Git's branches. Also, Mercurial supports even lighter branching compared to Git using anonymous branches. This blog post from 2009 explains it al…

> Not true.

Mostly true. I've read the post you linked to; all of those approaches have significant disadvantages compared to standard git branches. We used the bookmark-based workflow for a while, and it's simply not as good as a git branch. The evolve extension and topics were build for this reason, and they finally approach a decent workflow that allows for things like cleanly discarding experimental "branches" that have been pushed to a remote.

Post reply on HN