Live data from Hacker News

Sourcehut welcomes Bitbucket refugees

sourcehut.org

101–110 of 219 posts

Re: Sourcehut welcomes Bitbucket refugees

#101

I am looking to preserve the pull requests and corresponding comment threads from bitbucket. I'm thinking the way to go might be to save static HTML of the pages and host them somewhere, modifying the links to issues to point to migrated ones, and links to PRs to the hosted pages. Anyone else thinking of trying this approach? Advice, criticism?

At some point it should be possible to adjust the import script to also generate an mbox of pull requests discussions and import it into lists.sr.ht, but that's a lot more complicated. Happy to talk over the details if anyone is interested in taking a crack at this.

Re: Sourcehut welcomes Bitbucket refugees

#102

Earlier quoted context omitted.

Clicking the text "100% open source software" brings you to the following list of git repos which collectively contain the source code for sourcehut: https://git.sr.ht/~sircmpwn/?search=sr.ht

Can you make "sr.ht git services" the blue title of the repo "card" and "~sircmpwn/git.sr.ht" - the subtitle (with dimmed color)? This simple change will improve UI usability in 10x times.

I sort of agree about the confusion.

I think the proper UI fix would be to split the username (sircmpwn) from the repo name (git.sr.ht) and make them two separate links divided by a non-link " / ".

This is what github does and I feel like it's a standard people expect, similar to having the logo of a page on the top left.

Re: Sourcehut welcomes Bitbucket refugees

#103

Earlier quoted context omitted.

Bots? I have a hard time beleiving that a paid service has a silent fanbase. But maybe they do.

I'm a wanting-to-be paying user, fwiw. It goes against some of Sourcehut's fundamentals, but I'm waiting for a basic PR UI system, because frankly I just don't like email that much. (though strangely, I love the model of email) . Regardless, I adore the goals of the service and the approach, so my plan is to move all my public and private projects there once I can use a PR-UI/etc - and pay, of course.

I think you should give email its fair shake. There's a good tutorial here:

https://git-send-email.io

And the video on this website shows you how the maintainer side could work:

https://aerc-mail.org

And remember, the email client you use for hacking needn't be the same as your everyday client.

Re: Sourcehut welcomes Bitbucket refugees

#104

Earlier quoted context omitted.

`git instaweb` is sufficient to get a working gitweb stood up.

$ git instaweb lighttpd not found. Install lighttpd or use --httpd to specify another httpd daemon. Apparently, not.

You have to install the dependencies of a piece of software to use that piece of software.

Re: Sourcehut welcomes Bitbucket refugees

#105
post #65

Earlier quoted context omitted.

It's written in Python so as soon as they have enough users it will be as slow as any webpage with tons of JS. Thankfully, that CPU load won't be on the client side... so it's still an improvement

I recommend you relax your convictions about Python performance a bit. Server-side bottlenecks are more often than not database reads/writes and other IO. And the few CPU-intensive operations can be delegated to libraries written in C. Pure Python is slow for CPU-intensive tasks, but that doesn't mean that a Python webserver is necessarily slow.

This. There are also several optimized versions of python, other that stock, allowing you to increase performance based on your needs. I've shipped with many of them over the years.

Re: Sourcehut welcomes Bitbucket refugees

#106
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?

There are a few good things about it compared to git (and a few bad ones). One I like is that it has an excellent GUI that is cross platform, called TortoiseHg. I know hackers can be a bit snobbish about GUIs but I really think a GUI is essential for version control: flicking through the revision graph in one pane while looking at the modified files in another and a file's changes in a third is much more efficient th…

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 grad students who can code somewhat but are unlikely to have used version control before interacting with our project. Having a universal GUI was excellent for mentoring people and spreading the knowledge around. It's going to be much harder with git (since we are moving to github - I like what sourcehut is doing for devs, but email-based pull requests will mean we get very few contributors who aren't already seasoned devs, so we have decided against it for now).

From my experimenting, I'm liking Sublime Merge as my favourite git GUI so far. It's nagware (i. e. no time limit evaluation period) like sublime text, and costs US$99 to remove the nag and enable the dark theme. It is pretty and functional without being overwhelming in its interface.

Re: Sourcehut welcomes Bitbucket refugees

#107

Earlier quoted context omitted.

I'm a wanting-to-be paying user, fwiw. It goes against some of Sourcehut's fundamentals, but I'm waiting for a basic PR UI system, because frankly I just don't like email that much. (though strangely, I love the model of email) . Regardless, I adore the goals of the service and the approach, so my plan is to move all my public and private projects there once I can use a PR-UI/etc - and pay, of course.

I think you should give email its fair shake. There's a good tutorial here: https://git-send-email.io And the video on this website shows you how the maintainer side could work: https://aerc-mail.org And remember, the email client you use for hacking needn't be the same as your everyday client.

Huh. That never occurred to me. To use a different client for workflow email. That was sort of one of the things keeping me from trying this out for real. I was just, "Ugh, I don't want all that mixed up together." Even folders don't help that much because my main email client is already managing a ton of email accounts.

I'll have to give this idea a shot now. Thanks!

Re: Sourcehut welcomes Bitbucket refugees

#108
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?

There are a few good things about it compared to git (and a few bad ones). One I like is that it has an excellent GUI that is cross platform, called TortoiseHg. I know hackers can be a bit snobbish about GUIs but I really think a GUI is essential for version control: flicking through the revision graph in one pane while looking at the modified files in another and a file's changes in a third is much more efficient th…

I know you said GUI, but this single-line git alias that goes in ~/.gitconfig changed my life and I don't look for a git GUI anymore:

    [alias]
 l = log --date-order --date=iso --graph --full-history --all --pretty=format:'%x08%x09%C(red)%h %C(cyan)%ad%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08 %C(bold blue)%aN%C(reset)%C(bold yellow)%d %C(reset)%s'
Next, go to one of your git project directories and type "git l"

If you don't want to learn rebasing and other Git fun, I'm not sure how much this will help you, but for me it's invaluable when it comes to identifying the base of my branch and where I would like to transplant it to.

Along with the basic "git pull --rebase" I also frequently use "git rebase --onto" and "git pull --rebase=merges" or "git rebase --rebase-merges" in my projects in order to manage branches that were created in an order other than what I want them to merge in. This keeps the history nice and linear, so I can avoid having any commits with two or more parent commits.

I don't find there's much else I would want to have a GUI to help with. But without a git graph that I can scroll freely, I feel as if I could not do my day-to-day work with such ease. This makes the most usable git graph with colorized edges and may be all you need. That, along with a nice PS1 setting so you get some branch status information right in your terminal status line without asking for it every time.

Re: Sourcehut welcomes Bitbucket refugees

#109
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?

Honestly, years ago after I took a job that uses git, I converted a Mecurial repository to github. I don't remember what tool I used, but it preserved all my history.

Granted, this was a personal project and I didn't use much branching, but I remember the transition and history were pretty seamless.

I originally started with Bitbucket, and then transitioned to a small hosting service after Bitbucket had extended downtime. (I just had to update my Mecurial repository to push to a new host.) Then, the transition to github was almost as easy.

(If only I could remember the tool I used. Maybe my private Mecurial host allowed pulling with git? I just don't remember!)

Re: Sourcehut welcomes Bitbucket refugees

#110
post #69
post #43

Earlier quoted context omitted.

There’s not even any analytics or trackers. The shame!

Perhaps one could use greasemonkey to inject Google analytics into arbitrary sites. (And load some font, and perhaps have a 20 second timeout somewhere.)

Don't forget Facebook like buttons, those really need to be front and center on every page.
Post reply on HN