Live data from Hacker News

You already have a Git server

maurycyz.com

251–260 of 454 posts

Re: You already have a Git server

#251

Earlier quoted context omitted.

Depends on what you mean by using etc. If somebody asked me if it's possible to scp my git repo over to another box and use it there or vice versa, I would have said, yes, that is possible. Although I would've felt uneasy doing that. If somebody asked me if git clone ssh:// ... would definitely work, I wouldn't have known out of the gate, although I would have thought it would be neat if it did and maybe it does. I m…

Am I misreading your comment? You’ve always used GitHub but never known it could work over ssh? Isn’t it the default method of cloning when you’re signed in and working on your own repository…?

[deleted]

Re: You already have a Git server

#252
post #242

Earlier quoted context omitted.

git over nfs ... not the very best idea.

I haven't tried it, but I think it's fine if only one person has write access to any given clone. You can pull back and forth between clones freely. It's if you have two Git clients trying to write to the same repo that you'll have problems.

Shared write access to the same git repo directory can be done sanely, but you have to get a number of things right (same group for all users, everything group writable, sticky bit on directories, set config core.sharedRepository=group): https://stackoverflow.com/a/29646155

Re: You already have a Git server

#253
post #234

Earlier quoted context omitted.

But what, exactly, was pwned? Did you have secrets in the git repo?

I expose the .git directories on my web server and never considered it a problem. I also expose them on GitHub and didn't consider that a problem either...

Super common failure is accidental commit of a secret key. People suck at actually deleting something from git history. Had one colleague leak a Digital Ocean key this way with an accidental env file commit. He reverted, but the key is of course still present in the project history.

The speed at which an accidentally committed and reverted key is compromised and used to say launch a fleet of stolen VPSes on a github public repo nowadays is incredible. Fortunately most of the time your provider will cancel the charges...

This has always been the roughest part of git for me, the process to remove accidentally committed sensitive content. Sure we should all strive not to commit stupid things in the first place, and of course we have tools like gitignore, but we are all only human.

> https://docs.github.com/en/authentication/keeping-your-accou...

"Sensitive data can be removed from the history of a repository if you can carefully coordinate with everyone who has cloned it and you are willing to manage the side effects."

Re: You already have a Git server

#254
Git post-update hooks to do deployment FTW. I looked into the whole push-to-github to kick off CI and deployment; but someone mentioned the idea of pushing over ssh to a repo on your server and having a post-update hook do the deployment, and that turned out to be much simpler.

Re: You already have a Git server

#255

Earlier quoted context omitted.

I've been using git since 2007, this only dawned on me last year. Git is especially prone to the sort of confusion where all the experts you know use it in slightly different ways so the culture is to just wing it until you're your own unique kind of wizard who can't tie his shoes because he favors sandals anyhow.

The Pro Git book is available online for free https://git-scm.com/book/en/v2

This sort of thing is part of the problem. If it takes reading such a long manual to understand how to properly use Git, it's no wonder everyone's workflow is different.

Re: You already have a Git server

#256

Earlier quoted context omitted.

If you are working in a large corp and not your own side project, that honestly does sound like a bad idea.

It's not. Unless you work at a shitty place, something like what OP mentioned is far from a big deal and most people would wanna know more about it

The code is considered IP of the corp and they probably have rules around how or where IP should be shared, access controls etc.

Re: You already have a Git server

#257

Earlier quoted context omitted.

People said the same thing about “advanced” operations with cvs and svn (and just called their admin for p4 or source safe). But I really don’t understand the sentiment. Managing code is one of the cornerstones of software engineering. It would be like refusing to learn how to use a screwdriver because someone really just wants to hammer things together. The great thing about $your-favorite-scm is that it transcends…

> Managing code is one of the cornerstones of software engineering. It would be like refusing to learn how to use a screwdriver because someone really just wants to hammer things together. Ok, then make the commands make sense. For example 90%+ people has no idea what rebase does, yet it is a useful command. People does not want to learn with git outside of what works, because they can't experiment. The moment they w…

You can definitely experiment. Make a copy of the directory and experiment on that copy without pushing. I have done it a million times.

Re: You already have a Git server

#258
post #196

You probably want to use a bare repository (git init --bare) rather than `git config receive.denyCurrentBranch updateInstead`, which will cause your pushes to fail if you edit anything locally in the checkout. For http://canonical.org/~kragen/sw/dev3/ I run a pull from the post-update hook of http://canonical.org/~kragen/sw/dev3.git , http://canonical.org/~kragen/sw/dev3.git/hooks/post-update , which is short enough…

regarding that post-update script, can you explain?

I would think you'd want to

      cd /home/kragen/public_html/sw/dev3
      git update-server-info
      git pull
..in that order.

And I wouldn't think you'd need to run git update-server-info again, after git pull. My understanding isthe update-server-info makes updates to info/refs , which is necessary _after a push_.

What am I missing?

Re: You already have a Git server

#259

Earlier quoted context omitted.

Yes. I've been subject to claims that a single person can't start a project unless and until an official, centralized repo is setup for them. I've responded with "git init is all that is necessary to get started", but they wouldn't hear it.

Depends, what's the reasoning? Because technically anyone can start a project even without Git. Or even without a computer. Someone can use a pen to write code on a paper. Depends on what you mean by "a project". If it's policy related, maybe it's company's policy that all code that is written must be stored in a certain way for multitude of reasons.

They don't have a reason. There's no policy that keeps them from doing this. Sure, the whole point is to ultimately have the code in a common place where backups and code review can happen, but if it's a matter of starting something sooner because it takes a few days for the request to flow through to get things set up, they are not constrained by that AT ALL. They can create a git repo with git init immediately, start working, and once the repo is set up in the common area, git push all their work into it. Rather than train people on this, we spend time trying to hasten the common area repo setup time and put additional unneeded burden on the team responsible for that.

Re: You already have a Git server

#260
post #221

Earlier quoted context omitted.

> “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.

[deleted]
Post reply on HN