I think this is also possible with GitHub's own 'gh' tool?

I'm afk, but iirc it's `gh repo create`.

Nice job taking the time to build it out!

For what it's worth, "gh" works quite well and has all kinds of functionality. "gh re --create" would replicate the functionality here as far as I can tell.

Nice little tool. This has reminded me that I should put all the initial GitHub commands, for pushing an entire directory, into an alias, script, or binary. Or, learn the gh command, apparently.

I love a little bash script as much as anyone, but the official GitHub CLI is a better choice here, as it handles authentication with the API much more smoothly. Even if you just used it to make authenticated API calls, it’d be preferable to curl.

You also don’t have any error handling.

this. i'm all for little utility scripts like this but it'd be much easier to do with gh

Also, i wouldn't recommend a thing that you have to copy into your repo. Better to just have wrappers like this that live in your personal bin directory and get run from within the folder.

so, to summarize:

1. nifty idea

2. most of the steps are easier via gh

3. don't copy scripts into a dir, to run them. just leave them in your path.

Thx ! I'll modify this programme for the better one.

In general I would tend to agree, but have lately took a look at the gh dependencies this tool draws in today? [0]

This is not a (classic) unix cli tool, as it was some month before. Do you think anyone will be ever able to make a codereview? Like done for git [1]?

[0] https://github.com/cli/cli/blob/trunk/go.mod

[1] https://x41-dsec.de/security/research/news/2023/01/17/git-se...

On the other side: a simple and easy to understand plaintext curl one-liner.

I love that GitLab allows you to just push your repository directly:

https://docs.gitlab.com/ee/user/project/working_with_project...

Unfortunately, I keep forgetting about that and keep creating the project by hand (also gives me some time to pause and think about naming / description, and set repo visibility for a public project).

UPD: Gitea / Forgejo takes it one step further and allows you to specify visibility when pushing like this:

    git push -o repo.private=false -u [email protected]:example/hello master

(Doesn't seem to work on Codeberg, though)

https://docs.gitea.io/en-us/push-options/

This page is not readable on my iPhone :(

Here is a more readable version of that same page: https://archive.is/nRpOi#create-a-new-project-with-git-push

Huh, that's weird – I've just checked and it looks fine on my Android, and in Safari in responsive design mode. :thinking:

I think this tool has merit where gh doesn't, in that it can/could integrate with other hosts.

Github is a cancer on the git community - I know we tend to like "easy, fast, convenient" so mega-providers like GH or Gitlab are bound to occur, but we invariably find the downsides (centralized censorship, product placement, loss of features or random security vulns due to companies forgetting that the "simple" system is actually built on something complex) in the longterm.

I'm not saying GH shouldn't exist, what would be even cooler is if a tool like wfh, in addition to pushing folders to github/gitlab, could push folders to arbitrary servers - if you own the domain/server and have the appropriate access, brand new git repo auto-hosted.

It's not that bad actually, self-hosting is a thing – if you own the server, just set up your own Gitea or GitLab CE or something.

Shameless plug: I'm working on a tool which lets you get Gitea (or anything else that can be run with a docker-compose) running on a server in a couple minutes. You can install it with a single curl | sh, then you get a nice panel in which you can paste your Compose file, make a couple tweaks and click Deploy.

Gitea is actually the example app I picked for tutorial: https://lunni.dev/deploy/

There was an effort (though it seems to have died out) to bring federation to "software forges" (vcs + ci, etc).

I love the idea of having a standard way of repos and CI such that everyone brings their own forge, builds their contribution out and upstreams.

I’d add that, even when you put aside everything you mentioned, GitHub isn’t even a good product to host your company’s code.

It’s designed like a social network for open source stuff and it really shows in the UX.

However, most companies uses GitHub to host their private repos and GitHub is pretty dumb at it. The core feature companies will use is Pull Requests but the implementation is garbage vs GitLab. The rest is either useless in corporate environment or not good enough.

From my experience, GitHub is everywhere because founders used it by automatism and by the time you’d feel like you need an alternative, it’s too much pain to change anyway.

I’ve never seen any company having any reason to and wanting to transition from something else (except from SVN) to GitHub.

Agreed. These platforms want you locked in. Having agnostic tools helps you sleep at night, and keep them more honest than they might be otherwise.

You're looking at the per-repo settings of gitea there - obviously push-to-create doesn't fit there (;

It's enabled for users/orgs via env vars ENABLE_PUSH_CREATE_USER/ENABLE_PUSH_CREATE_ORG. DEFAULT_PUSH_CREATE_PRIVATE sets whether new repos should be public or private (ideally this would be configurable by the user but oh well).

https://docs.gitea.io/en-us/config-cheat-sheet/#repository-r...

If Codeberg doesn't have t enabled, maybe suggest they enable it?

VAX VMS had a concept of file versioning in their file system, looks like this tool goes towards that direction.

I prefer:

    brew install hub
    alias git=hub
    git create [-p] [[org/][repo name]]

You’re probably better off with gh rather than hub these days; it’s the official way forwards for CLI Github access.

https://cli.github.com/

One feedback/idea in regards to the API: instead of using positional arguments, the parameters could also be named flags, i.e. `wfh.sh --user shunak --visibility public`. That’s slightly more verbose, but it would make it easier for the parameters to be optional. For example, the Github username could read its default from an environment variable, because in many cases it probably stays the same anyway. Or, if you don’t specify `--visibility`, then it defaults to `public` (just like on Github).

That way, you could also optionally offer to set the repo name to something different than the folder name, e.g. `--name some-arbitrary-name`.

On this topic one of the most bewildering and frustrating trends I see is when people create a GitHub repository, but don't check include README.md.

This results in a totally blank repository and just a page of git commands to run to set it up yourself locally, set origin, commit some junk file to get started, and then finally push. This takes a couple of minutes.

Compared to: Create GitHub repository, have README.md included, and then just clone it locally. 20 seconds.