Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You already have a Git server

maurycyz.com

Post reply on HN
Print view View original

221–230 of 454 posts

Re: You already have a Git server

#221

Post by mzajc »

jonhohle wrote: post #98

I feel like something was lost along the way. git init —-bare will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`. “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. You can even namespace where you push back to th…

> “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like.

One remote can also hold more URLs! This is arguably more obscure (Eclipse's EGit doesn't even support it), but works wonders for my workflow, since I want to push to multiple mirrors at the same time.

Re: You already have a Git server

#222

Post by pwdisswordfishy »

kawsper wrote: post #146
jonhohle wrote: post #98

I feel like something was lost along the way. git init —-bare will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`. “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. You can even namespace where you push back to th…

I always thought it would have been better, and less confusing for newcomers, if GitHub had named the default remote “github”, instead of origin, in the examples.

GitHub could not name it so, because it's not up to GitHub to choose.

Re: You already have a Git server

#223

Post by mckn1ght »

mzajc wrote: post #221
jonhohle wrote: post #98

I feel like something was lost along the way. git init —-bare will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`. “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. You can even namespace where you push back to th…

> “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. One remote can also hold more URLs! This is arguably more obscure (Eclipse's EGit doesn't even support it), but works wonders for my workflow, since I want to push to multiple mirrors at the same time.

Whenever I fork a repo I rename origin to “fork” and then add the parent repo as a remote named “upstream” so i can pull from that, rebase any of my own changes in to, and push to fork as needed.

Multiple remotes is also how you can combine multiple repos into one monorepo by just fetching and pulling from each one, maybe into different subdirectories to avoid path collisions.

Re: You already have a Git server

#224

Post by jasode »

paulddraper wrote: post #213
Cheer2171 wrote: post #140

Earlier quoted context omitted.

> It doesn't include pull requests, when cloning from github, though. Because GitHub pull requests are a proprietary, centralized, cloud-dependent reimplementation of `git request-pull`. How the "free software" world slid head first into a proprietary cloud-based "open source" world still boils my blood. Congrats, Microsoft loves and owns it all, isn't that what what we always wanted?

Having a web interface was really appreciated by users, it would seem.

>Having a web interface

It's not the interface, it's the web hosting. People want a free destination server that's up 24/7 to store their repository.

If it was only the web interface, people could locally install GitLab or Gitea to get a web browser UI. (Or use whatever modern IDE code editor to have a GUI instead of a CLI for git commands.) But doing that still doesn't solve what GitHub solves: a public server to host the files, issue tracking, etc.

Before git & Github, people put source code for public access on SourceForge and CodeProject. The reason was the same: a zero-cost way to share code with everybody.

Re: You already have a Git server

#225

Post by mckn1ght »

kawsper wrote: post #146
jonhohle wrote: post #98

I feel like something was lost along the way. git init —-bare will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`. “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. You can even namespace where you push back to th…

I always thought it would have been better, and less confusing for newcomers, if GitHub had named the default remote “github”, instead of origin, in the examples.

Is this something the remote can control? I figured it was on the local cloner to decide.

Can’t test it now but wonder if this is changed if it affects the remote name for fresh clones: https://git-scm.com/docs/git-config#Documentation/git-config...

Re: You already have a Git server

#226

Post by cycomanic »

I suspect many who always use git remotely don't know that you can easily work with local repositories as well using the file protocol, git clone file:///path/to/repository will create a clone of the repository at the path.

I used that all the time when I had to move private repositories back and forth from work, without ssh access.

Re: You already have a Git server

#227

Post by udev4096 »

Cheer2171 wrote: post #140
webstrand wrote: post #128

Earlier quoted context omitted.

git clone --mirror is another good one to know, it also makes a bare repository that is an exact clone (including all branches, tags, notes, etc) of a remote repo. Unlike a normal clone that is set up for local tracking branches of the remote. It doesn't include pull requests, when cloning from github, though.

> It doesn't include pull requests, when cloning from github, though. Because GitHub pull requests are a proprietary, centralized, cloud-dependent reimplementation of `git request-pull`. How the "free software" world slid head first into a proprietary cloud-based "open source" world still boils my blood. Congrats, Microsoft loves and owns it all, isn't that what what we always wanted?

It still blows my mind how git has lost it's original ideas of decentralized development because of github and how github, a for-profit - centralized - close-sourced forge, became the center for lots of important open source projects. We need radicle, forgejo, gitea to catch up even more!

Re: You already have a Git server

#228

Post by seba_dos1 »

pwdisswordfishy wrote: post #222
kawsper wrote: post #146

Earlier quoted context omitted.

I always thought it would have been better, and less confusing for newcomers, if GitHub had named the default remote “github”, instead of origin, in the examples.

GitHub could not name it so, because it's not up to GitHub to choose.

There are places where it does choose, but arguably it makes sense for it to be consistent with what you get when using "git clone".

Re: You already have a Git server

#229

Post by udev4096 »

jasode wrote: post #224
paulddraper wrote: post #213

Earlier quoted context omitted.

Having a web interface was really appreciated by users, it would seem.

>Having a web interface It's not the interface , it's the web hosting . People want a free destination server that's up 24/7 to store their repository. If it was only the web interface, people could locally install GitLab or Gitea to get a web browser UI. (Or use whatever modern IDE code editor to have a GUI instead of a CLI for git commands.) But doing that still doesn't solve what GitHub solves: a public server to…

GH is essentially an unlimited storage space. There are countless scripts which makes it possible to even use it as an unlimited mounted storage

Re: You already have a Git server

#230

Post by mvanbaak »

superdisk wrote: post #79
politelemon wrote: post #22

Earlier quoted context omitted.

Also relatively unknown: You can clone from a directory. It won't accomplish the backup feature but it's another option/feature.

If you do it over NFS or whatever then you can collaborate as well.

git over nfs ... not the very best idea.
Post reply on HN