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

141–150 of 454 posts

Re: You already have a Git server

#141

Post by mbork_pl »

rester324 wrote: post #64
ezst wrote: 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

Staging is immensely useful in more than one case.

Case one: WiP on a branch, code is pretty stable, but I want to do some experiments which will likely be deleted. I stage everything and then make (unstaged) changes which I can then undo with two keystrokes.

Case two: I'm reviewing a complex PR, so I first merge it with --no-commit, then unstage everything and then stage chunks (or even individual lines) I have already reviewed.

Case three: I was coding in the state of flow and now I have a lot of changes I want to commit, but I want to separate them into several atomic commits. I stage the first batch of changes, commit, then stage another, commit, etc.

There are probably more, but these three alone are worth having the staging area.

Re: You already have a Git server

#142

Post by jonhohle »

tangotaylor wrote: post #112

Beware of using this to publish static sites: you can accidentally expose your .git directory to the public internet. I got pwned this way before (by a pentester fortunately). I had to configure Apache to block the .git directory.

Instead of excluding non-public directories, I like to make an explicit `public` directory (or `doc`, `doc-root`, whatever you want to call it). Then configure your server to point to that subdirectory and don’t worry about the repo.

I usually throw `etc` and `log` directories at the top level as well and out my server config in etc, and have a gitignite rule to ignore everything in logs, but it’s there and ready for painless deployment.

Since the web root is already a sub directory, more sensitive things can go into the same repo without worrying about exposing them.

Re: You already have a Git server

#143

Post by prmph »

The more I use git, the more I discover more depth to it.

So many features and concepts; it's easy to think you understand the basics, but you need to dig deep into it's origin and rationale to begin to grasp the way of thinking it is built around.

And the API surface area is much larger than one would think, like an iceberg

So I find it really weirdly low level in a way. Probably what is needed is is a higher-level CLI to use it in the most sensible, default way, because certainly the mental model most people use it with is inadequate.

Re: You already have a Git server

#144

Post by singpolyma3 »

rco8786 wrote: post #138
haskellshill wrote: post #132

Earlier quoted context omitted.

> all the experts you know use it in slightly different ways What? Knowing that a git repo is just a folder is nowhere near "expert" level. That's basic knowledge, just like knowing that the commits are nodes of a DAG. Sadly, most git users have no idea how the tool works. It's a strange situation, it'd be like if a majority of drivers didn't know how to change gears.

The majority of drivers DON’T know how to change gears. You are simultaneously saying that something is not expert level knowledge while acknowledging that most people don’t know it. Strange.

I think the idea is it shouldn't be expert level. It used to be in every tutorial. But you're right these days it may indeed be expert level knowledge

Re: You already have a Git server

#145

Post by Sharlin »

jonhohle wrote: post #133
Sharlin wrote: post #123

Earlier quoted context omitted.

Git was always explicitly a decentralized, "peer to peer" version control system, as opposed to centralized ones like SVN, with nothing in the protocol itself that makes a distinction between a "server" and a "client". Using it in a centralized fashion is just a workflow that you choose to use (or, realistically, one that somebody else chose for you). Any clone of a repository can be a remote to any other clone, and…

This is a better summary than mine. There was a thread not to long ago where people were conflating git with GitHub. Git is an incredible tool (after coming from SVN/CVS/p4/source safe) that stands on its own apart from hosting providers.

And GitHub naturally has done nothing to disabuse people of the interpretation that git = GitHub. Meanwhile, the actual raison d'etre for the existence of git of course doesn't use GitHub, or the "pull request" based workflow that GitHub invented and is also not anything intrinsic to git in any way.

Re: You already have a Git server

#146

Post by kawsper »

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.

Re: You already have a Git server

#147

Post by seba_dos1 »

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?

They are available as refs on the remote to pull though, they just aren't listed so don't end up mirrored either.

Re: You already have a Git server

#148

Post by Sophira »

webstrand wrote: post #131
Sharlin wrote: post #123

Earlier quoted context omitted.

Git was always explicitly a decentralized, "peer to peer" version control system, as opposed to centralized ones like SVN, with nothing in the protocol itself that makes a distinction between a "server" and a "client". Using it in a centralized fashion is just a workflow that you choose to use (or, realistically, one that somebody else chose for you). Any clone of a repository can be a remote to any other clone, and…

It's a little more complex than that. Yes git can work in a peer-to-peer fashion, but the porcelain is definitely set up for a hub-and-spoke model, given how cloning a remote repo only gives you a partial copy of the remote history. There's other stuff too, like git submodules can't be configured to reference another branch on the local repository and then be cloned correctly, only another remote.

> given how cloning a remote repo only gives you a partial copy of the remote history

You may be thinking of the optional -depth switch, which allows you to create shallow clones that don't have the full history. If you don't include that, you'll get the full history when cloning.

Re: You already have a Git server

#149

Post by jrm4 »

Cannot emphasize this whole notion enough; Very roughly, Github is to git what gmail is to email.

It's mostly probably fine if that's the thing most of everybody wants to use and it works well; but also it's very unwise to forget that the point was NEVER to have a deeply centralized thing -- and that idea is BUILT into the very structure of all of it.

Re: You already have a Git server

#150

Post by masklinn »

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.

How is it less confusing when your fork is also on github?
Post reply on HN