Hacker News Reader

Hacker News

Comment by yjftsjthsd-h | Hacker News Reader

Parent Full thread

yjftsjthsd-h

Alright, cue the usual:

Monoculture bad

Microsoft bad

Git is distributed but all the things around it that we really need aren't

You can set up git to push to multiple remotes automatically

Nobody is actually using git in distributed mode

Did I forget anything?

View on HN

The conspiracy about how much infrastructure has been going down this summer, and how it's probably interns / a state actor / people pushing to get things in production before performance reviews / people being on holiday / that we've reached peak complexity.

You forgot my favorite: senior people leaving for greener/less stressful pastures.

Seriously though this summer has been unusually bad ceteris paribus right? We need a State of the SaaS address.

Give us some credit: it's the best 2019 we've had so far!

2019 BC doesn't even have a Wikipedia page!

Conspiracy of people being on holiday?

The usual fluff about migrating away to Gitlab?

"Just run gitea/gogs in a raspberry pi in the closet, works for me"

I hide mine in a Barnes & Noble

That’s smart. No one will ever find it.

That should do it.

cue somebody asking the difference and a paragraph explaining the drama that unfolded between them

For many companies it's not just about running Git server. It's team productivity and all the tooling around it.

Irony of ironies. Gitlab's import-from-GitHub functionality has been broken ever since we tried to migrate away. (They're going ot fix it soon.)

I'm sorry you had a bad experience with this.

The importer can still get better but we're importing about 500 projects per hour at peak https://www.dropbox.com/s/hr3ndcmu21aehmk/Screenshot%202019-...

Some imports work. The ones that failed are those with release notes (which were also the more important ones). And they fail silently (succeeded but no releases imported), which is annoying. I could dig up the issue numbers.

I'm generally very pleased with GitLab. I'm delighted that it's open source.

Glad to hear; I'd really like to see us improve some of our import capabilities at GitLab. We've created a separate team specific to importers and have started moving much more quickly here. Thanks for your patience.

Please let me know if this issue addresses the problem you encountered, would love to make sure we're prioritizing it. https://gitlab.com/gitlab-org/gitlab-ce/issues/20780

I think these issues were implicated:

https://gitlab.com/gitlab-org/gitlab-ce/issues/65194 https://gitlab.com/gitlab-org/gitlab-ce/issues/52956

No idea when these are going to be deployed. 12.2, 12.3, 12.5... But I'll keep checking in and trying the import every few weeks.

I did this for the first time 2 days ago on two medium-size GH repos and it while was crazy slow, it eventually completed after about 8 hours or so. The actual bits seemed to finish in a relatively quick amount of time, but the project landing page continually showed "import in progress" for all those 8 hours.

Git is simple to import, but all other related data may be subject to API rate limits.

I've opened an issue with some improvements suggestions, like surfacing when we are rate limited and allowing gradual access to the data while the import is going on: https://gitlab.com/gitlab-org/gitlab-ce/issues/66525

"We would migrate to Gitlab, but it's currently down"

Given the context I guess he is talking about the self-hosted version.

See also https://gogs.io/

I hope to see a trend towards "you can host a Git repository yourself, why do you depend on GitHub?".

Publicly visible outages on "pro" internet properties are actually a good thing because they help correct the views so commonly held by low-information executives about 5-nines and uptime. The more ammo people have, in aggregate, that "XXX never goes down" is a lie, the better off we will be as an industry.

If GitHub actually had an open source version, then I could selfhost on infrastructure that I trust.

Wait till you hear about Phabricator! It was a Facebook tool that got open sourced and then the devs spun out their own company to provide paid support and whatnot. But you can just self-host it and frankly, it's glorious.

https://www.phacility.com/

I actually have, and even better it can easily be setup with Helm on a Kubernetes cluster:

https://github.com/helm/charts/tree/master/stable/phabricato...

at that rate wouldn't i just use gitlab

If you want a complete solution that mostly works, then yes. However, I think there is a lot of benefit in tools like Phabricator, or rolling your own SCM with Gitea and implementing Drone CI.

What about "rookie mistakes by code artisans who are making it up as they go along"?

> Git is distributed but all the things around it that we really need aren't

Can anyone recommend an issue tracker that is distributed with the repo?

I'm building one: https://github.com/MichaelMure/git-bug

@TODO comments strewn around in your repo.

I was thinking of something that wouldn't be affected by the git history. There's no point in having branches for issue comments.

Something like:

  $ git issue add "foo doesn't work"
  Created issue ece5591: foo doesn't work
  $ git issue comment ece5591 "the problem might be with bar"
  Created comment 0191fa1 on issue #10.
  $ git issue comment --reply 0191fa1 "or with baz"
  Created comment f98e783 on issue #10.
  $ git issue show ece5591
  foo doesn't work -- ece5591 Your Name <your@email>
    the problem might be with bar -- 0191fa1 Your Name <your@email>
      or with baz -- f98e783 Your Name <your@email>
  $ git issue push
  Pushed issues ece5591.
  $ git issue pull
  Pulled issues 3ebdc7e, 24cdb90.

EDIT: I just gave myself a clue:

https://github.com/dspinellis/git-issue

The nice idea to having issues in your history/branches is that it easily inverts the "flow" of branch state information: most issue trackers do a lot of work to figure which changes affect which issues, and which branches those changes are in. This often requires a lot of explicit manual work like making commit notes always include issue numbers for instance and "magic" commands like "Resolves #10" to auto-close issues.

If the issues are just another source artifact alongside the code in the same git history a lot of that information flows the other direction. Instead of a magic command in a commit note to close an issue, an issue closing shows up in a diff in the commit. Figuring out which issues are still open in a given branch (what isn't in our release branch yet?) is a simple command in a branch. Figuring out which issues changed between branches (what's finished in this feature branch that hasn't been merged to release yet?) is a typical diff operation.

In terms of documenting the state and progress of an individual branch in a complex project there can be a lot of magic in having issues tracked directly inside code branches. It's a fascinating ideal for code documentation to have issue comments, changes, and workflows side-by-side the code that changed with it.

That said, issue trackers are sadly not ideal code artifacts for a lot of reasons, including that it is easy to forget that issues aren't just for coders, but also stakeholders/product owners/PMs/etc.

There were a whole bunch of these being actively developed around 2009-2012, but all of them slowly died out because each one had at least one of several issues that made them difficult or annoying to use, usually either requiring forgettable steps to actually distribute, or polluting the commits/branches with their own tracking.

My personal solution is similar to sibling comments, but more structured - using vimwiki in a subdirectory inside the repo, and committing updates alongside the relevant code changes.

A commited todo.txt [1] file with project.

[1]: todotxt.org

The knowing meta-post.

And the meta-meta follow on.

Reply on news.ycombinator.com