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

331–340 of 454 posts

Re: You already have a Git server

#331

Post by scuff3d »

kragen wrote: post #330
scuff3d wrote: post #328

Earlier quoted context omitted.

If that's the case I'm assuming the commit itself is quite large then? Or maybe it would more accurate to say it can be large if all the changes logically go together? I'm thinking in terms of what I often see from people I work with, where a PR is normally made up of lots of small commits.

The idea is that you divide a large change into a series of small commits that each make sense in isolation, so that Linus or Greg Kroah-Hartman or whoever is looking at your proposed change can understand it as quickly as possible—hopefully in order to accept it, rather than to reject it.

Gotcha, that makes sense. Thanks, I've always been curious about how the Linux kernel works.

Re: You already have a Git server

#332

Post by pavon »

kragen wrote: post #242
mvanbaak wrote: post #230

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.

I've put private working copies on NFS and CIFS. NFS worked pretty well (which probably speaks as much to the admins as the tech). Samba mounts on the other hand had all sorts of problems with time stamps that confused not only git, but the build system as well.

Re: You already have a Git server

#333

Post by afavour »

udev4096 wrote: post #227
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?

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!

I don’t think it’s really that surprising. git didn’t become popular because it was decentralised, it just happened to be. So it stands to reason that part doesn’t get emphasised a ton.

Re: You already have a Git server

#334

Post by kragen »

scuff3d wrote: post #331
kragen wrote: post #330

Earlier quoted context omitted.

The idea is that you divide a large change into a series of small commits that each make sense in isolation, so that Linus or Greg Kroah-Hartman or whoever is looking at your proposed change can understand it as quickly as possible—hopefully in order to accept it, rather than to reject it.

Gotcha, that makes sense. Thanks, I've always been curious about how the Linux kernel works.

I may not be the best source for information, not having written anything worth contributing myself.

Re: You already have a Git server

#335

Post by lisbbb »

udev4096 wrote: post #227
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?

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!

I once worked at a smaller company that didn't want to shell out for github and we just hosted repos on some VM and used the ssh method. It worked. I just found it to be kind of clunky having come from a bigger place that was doing enterprise source control management with Perforce of all things. Github as a product was fairly new back then, but everyone was trying to switch over to Git for resume reasons there. So then I go to this smaller place using git in the classic manner.

Re: You already have a Git server

#336

Post by mook »

iwontberude wrote: post #206

“By default, git won’t let you push to the branch that is currently checked out” TIL that people use non-bare git.

I use non-bare git because it's just transferring code between multiple machines for cross-platform locally run software; that is, it's just checkouts on mac, Windows, and Linux and commits being pushed amongst them. But then I also use worktrees and stuff, so maybe I'm weird.

Re: You already have a Git server

#337

Post by wizzwizz4 »

jonhohle wrote: post #142
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…

Storing volatile data (e.g. logs) in the git-managed directory is an excellent way to lose all your data. https://fediverse.blog/~/Prismo/on-prismo-data-loss

Re: You already have a Git server

#338

Post by viraptor »

udev4096 wrote: post #227
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?

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!

It didn't really lose the original ideas. It just never learned that people don't want to use it the way kernel devs want to use it. Git never provided an easy github-like experience, so GitHub took over. Turns out devs in general are not into the "setup completely independent public mailing lists for projects" idea.

Re: You already have a Git server

#339

Post by scuff3d »

kragen wrote: post #334
scuff3d wrote: post #331

Earlier quoted context omitted.

Gotcha, that makes sense. Thanks, I've always been curious about how the Linux kernel works.

I may not be the best source for information, not having written anything worth contributing myself.

Well I appreciate it none the less.

I think the point I always get stuck on is how small is "small" when we're talking about commits/patches. Like if you're adding a new feature (to anything, not necessarily the Linux Kernel), should the entire feature be a single commit or several smaller commits? I go back and forth on this all the time, and if you research you're gonna see a ton of different opinions. I've seen some people argue a commit should basically only be a couple lines of code changed, and others argue it should be the entire feature.

You commonly hear Linus talk about commits/patches having very detailed descriptions attached to them. I have trouble believing people would have time for that if each commit was only a few lines, and larger features were spread out over hundreds of commits.

Re: You already have a Git server

#340

Post by kragen »

scuff3d wrote: post #339
kragen wrote: post #334

Earlier quoted context omitted.

I may not be the best source for information, not having written anything worth contributing myself.

Well I appreciate it none the less. I think the point I always get stuck on is how small is "small" when we're talking about commits/patches. Like if you're adding a new feature (to anything, not necessarily the Linux Kernel), should the entire feature be a single commit or several smaller commits? I go back and forth on this all the time, and if you research you're gonna see a ton of different opinions. I've seen so…

When I'm reviewing commits, I find it useful to see refactoring, which doesn't change behavior, separated from functional changes, and for each commit to leave the tree in a working, testable state. This is also helpful for git bisect.

Often, a change to a new working state is necessarily bigger than a couple of lines, or one of the lines has to get removed later.

I don't want to have to say, "Hmm, I wonder if this will work at the end of the file?" and spend a long time figuring out that it won't, then see that the problem is fixed later in the patch series.

Other people may have other preferences.

Post reply on HN