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.
Sourcehut welcomes Bitbucket refugees
211–219 of 219 posts
Re: Sourcehut welcomes Bitbucket refugees
#212Earlier 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?
Re: Sourcehut welcomes Bitbucket refugees
#213Serious 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…
Re: Sourcehut welcomes Bitbucket refugees
#214Earlier 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.
I also remember when you could register without an email.
Re: Sourcehut welcomes Bitbucket refugees
#215Earlier 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.
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
#216Serious 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…
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
#217Serious 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.
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
#218Earlier 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...
Re: Sourcehut welcomes Bitbucket refugees
#219Earlier 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…
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.