Live data from Hacker News

You already have a Git server

maurycyz.com

61–70 of 454 posts

Re: You already have a Git server

#61
post #38

I tried this and it is never as smooth as described. Why is GitHub popular? its not because people are "dumb" as others think. Its because GitHub "Just Works". You don't need obscure tribal knowledge like seba_dos1 suggests [0] or this comment https://news.ycombinator.com/item?id=45711294 The official Git documentation for example has its own documentation that I failed to get work. (it is vastly different from what…

People use github because it has a bunch of features outside git and because they don't already have a server.

Not because it's hard or obscure to put git on your server.

Re: You already have a Git server

#62
post #20

As a git user "not by choice" (my preference going for mercurial every single day), I never understood why git needs this distinction between bare/non-bare (or commit vs staging for that matter). Seems like yet another leaky abstraction/bad design choice.

A repo is as database containing a tree of commits. Then you got the concept of branch, which points to a specific commit. Then there's the special pointer HEAD which is the latest commit for the current worktree.

When you checkout (now switch) a branch, HEAD is now the same as the branch (they point to the same commit). When you do operation like commit, reset, reset,... both the head and the branch are updated. So if a remote node tries to update the local node via a push on its end, that would mess up the local worktree. So you create a bare repo instead which can't contain a local worktree.

Note: A worktree is computed from the initial commit to the commit currently identified by HEAD by following the parent information on each commit.

The staging area is like a stored snapshot of what you would like to commit. You can always create patch between HEAD and the worktree, edit it, and then save the patch as the commit, then apply the leftover to the worktree. The staging just make that easier. It's a WIP patch for the next commit.

Re: You already have a Git server

#63

Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?

What are some fun/creative ways to do GitHub/GitLab style CI/CD with this method? Some kind of entry point script on push that determines what to do next? How could you decide some kind of variables like what the push was for?

Re: You already have a Git server

#64
post #20

As a git user "not by choice" (my preference going for mercurial every single day), I never understood why git needs this distinction between bare/non-bare (or commit vs staging for that matter). Seems like yet another leaky abstraction/bad design choice.

Yeah, I am in the same boat. My files are either non-staged or committed about 99.99% of the time. For me the concept of staging is completely useless

Re: You already have a Git server

#65
post #3

Interesting. I am just trying to decide between self-hosting Forgejo and other options for hosting Git in own private network.

Forgejo is working okay for me. Hard to justify using SSH for Git. Principle of least power and all that

Git is distributed, so there's no least power and all that. Everyone has full power over their own copy. What you want is one copy being the source of truth. You can always use HTTP for read-only access to that copy with a limited set of people having write access to update the copy. Patches can be shared via anything (git has built-in support for email).

Re: You already have a Git server

#67
post #41

Earlier quoted context omitted.

Having to make a repo bare to not have issues with branches is definitely obscure.

It's obvious as soon as you consider that your push will overwrite a ref that's currently checked out in the target's repo workdir. The exact same thing happens when pushing to local repos. You don't have to make a repo bare to avoid this issue, but it's certainly the easiest way to avoid it altogether when you don't need a workdir on the server side.

It's obvious that it needs to update the ref. It's not obvious that this would cause any problems. You could fix HEAD as part of writing the ref. Automatically managing HEAD is normal git behavior.

Re: You already have a Git server

#68

Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?

What are some fun/creative ways to do GitHub/GitLab style CI/CD with this method? Some kind of entry point script on push that determines what to do next? How could you decide some kind of variables like what the push was for?

[deleted]

Re: You already have a Git server

#69
post #38

I tried this and it is never as smooth as described. Why is GitHub popular? its not because people are "dumb" as others think. Its because GitHub "Just Works". You don't need obscure tribal knowledge like seba_dos1 suggests [0] or this comment https://news.ycombinator.com/item?id=45711294 The official Git documentation for example has its own documentation that I failed to get work. (it is vastly different from what…

Are basic git concepts like bare repos "obscure tribal knowledge" these days? What do you think ".git" directory is?

Now try to add a submodule X (which is a bare repository) to your repository Y

Good job, now you can't add it nor remove it, without manually removing it in .git folder.

Re: You already have a Git server

#70

Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?

What are some fun/creative ways to do GitHub/GitLab style CI/CD with this method? Some kind of entry point script on push that determines what to do next? How could you decide some kind of variables like what the push was for?

I wrote about that idea here: https://www.stchris.net/tiny-ci-system.html
Post reply on HN